View AVR32UC10_4724673.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

feature summary ? small area, high clock frequency. 32-bit load/store avr32a risc architecture. 15 general-purpose 32-bit registers. 32-bit stack pointer, program counter and li nk register reside in register file. fully orthogonal instruction set. pipelined architecture allows one instruction per clock cycle for most instructions. byte, half-word, word and double word memory access. fast interrupts and multiple interrupt priority levels. privileged and unprivileged modes enablin g efficient and secure operating systems. optional mpu allows for operating systems with memory protection. innovative instruction set together with variable instruction length ensuring industry leading code density. dsp extention with saturating arithmetic, and a wide variety of mu ltiply instructions. memory read-modify-w rite instructions. optional advanced on-chip debug system. flashvault ? support through secure state for executing trusted code alongside nontrusted code on the same cpu. optional floating -point hardware. 32002f?03/2010 avr32uc technical reference manual
2 32002f?03/2010 avr32 1. introduction avr32 is a new high-performance 32-bit risc microprocessor core, designed for cost-sensitive embedded applications, with particular emphasis on low power consumption and high code den- sity. in addition, the instruction set architecture has been tuned to allow for a variety of microarchitectures, enabling the avr32 to be impl emented as low-, mid- or high-performance processors. avr32 extends the avr family into the world of 32- and 64-bit applications. 1.1 the avr family the avr family was launched by atmel in 1996 and has had remarkable success in the 8-and 16-bit flash microcontroller market. avr32 is complements the current avr microcontrollers. through the avr32 family, the avr is extended into a new range of higher performance appli- cations that is currently served by 32- and 64-bit processors to truly exploit the power of a 32-bit architecture, the new avr32 architecture is not binary com- patible with earlier avr architectures. in order to achieve high code density, the instruction format is flexible providing both compact inst ructions with 16 bits length and extended 32-bit instructions. while the instruction length is only 16 bits for most instructions, powerful 32-bit instructions are implemented to further increase performance. compact and extended instruc- tions can be freely mixed in the instruction stream. 1.2 the avr32 microprocessor architecture the avr32 is a new innovative microprocessor ar chitecture. it is a fully synchronous synthesis- able rtl design with industry standard interfaces, ensuring easy integration into soc designs with legacy intellectual property (ip). through a quantitative approach, a large set of industry recognized benchmarks has been compiled and analyz ed to achieve the best code density in its class of microprocessor architectu res. in addition to lowering the memory requirements, a com- pact code size also contributes to the core?s low power characteristics. the processor supports byte and half-word data types without penalty in code size and performance. memory load and store operations are provided for byte, half-word, word and double word data with automatic sign- or zero extension of half-word and byte data. the c-compiler is closely linked to the architecture and is able to expl oit code optimization features, both for size and speed. in order to reduce code size to a minimum, so me instructions have multiple addressing modes. as an example, instructions with immediates often have a compact format with a smaller imme- diate, and an extended format with a larger immediate. in this way, the compiler is able to use the format giving the smallest code size. another feature of the instruction set is that frequently used instructions, like add, have a com- pact format with two operands as well as an extended format with three operands. the larger format increases performance, allowing an addition and a data move in the same instruction in a single cycle. load and store instructions have several different formats in order to reduce code size and speed up execution: load/store to an address specified by a pointer register load/store to an address specified by a pointer register with postincrement load/store to an address specified by a pointer register with predecrement load/store to an address specified by a pointer register with displacement
3 32002f?03/2010 avr32 load/store to an address specified by a small immediate (direct addressing within a small page) load/store to an address specified by a pointer register and an index register. the register file is organized as 16 32-bit regi sters and includes the program counter, the link register, and the stack pointer. in addition, one re gister is designed to hold return values from function calls and is used imp licitly by some instructions. the avr32 core defines several micro architectures in order to capture the entire range of appli- cations. the microarchitectures are named avr32a, avr32b and so on. different microarchitectures are suited to different end applications, allowing the designer to select a microarchitecture with the optimum set of parameters for a specific application. 1.3 exceptions and interrupts the avr32 incorporates a powerful excepti on handling scheme. the different exception sources, like illegal op-code and external interrup t requests, have different priority levels, ensur- ing a well-defined behavior when multiple except ions are received simu ltaneously. additionally, pending exceptions of a higher priority class ma y preempt handling of ongoing exceptions of a lower priority class. each priority class has dedicated registers to keep the return address and status register thereby removing the need to perform time-consuming memory operations to save this information. there are four levels of external interrupt requests, all executing in their own context. an inter- rupt controller does the priority handling of the external interrupts and provides the prioritized interrupt vector to the processor core. 1.4 java support some avr32 implementations provide java hardware acceleration. to reduce gate count, avr32uc does not implement any such hardware. 1.5 flashvault revision 3 of the avr32 architecture introduced a new cpu state called secure state. this state is instrumental in the new security technology named flashvault. this innovation allows the on-chip flash and other memories to be partially programmed and locked, creating a safe on- chip storage for secret code and valuable software intellectual property. code stored in the flashvault will execute as normal, but reading, copying or debugging the code is not possible. this allows a device with flashvault code protec tion to carry a piece of valuable software such as a math library or an encryption algorithm from a trusted location to a potentially untrustworthy partner where the rest of the source code can be developed, debugged and programmed. 1.6 microarchitectures the avr32 architecture defines different microarchitectures, avr32a and avr32b. this enables implementations that are tailored to spec ific needs and applications. the microarchitec- tures provide different performance levels at the expense of area and power consumption. the avr32a microarchitecture is targeted at cost -sensitive, lower-end a pplications like smaller microcontrollers. this microarchitecture does not provide dedicated hardware registers for shad- owing of register file registers in interrupt contexts. additionally, it does not provide hardware registers for the return address registers and return status registers. instead, all this information is stored on the system stack. this saves chip area at the expense of slower interrupt handling.
4 32002f?03/2010 avr32 upon interrupt initiation, registers r8-r12 are automatically pushed to the system stack. these registers are pushed regardless of the priority level of the pending interrupt. the return address and status register are also automatically pushed to stack. the interrupt handler can therefore use r8-r12 freely. upon interrupt completion, the old r8-r12 registers and status register are restored, and execution continues at the return address stored popped from stack. the stack is also used to store the status register and return address for exceptions and scall . executing the rete or rets instruction at the completion of an exception or system call will pop this status register and continue execution at the popped return address. 1.7 the avr32uc architecture the first implementation of the avr32a architec ture is called avr32uc. this implementation targets low- and medium-performance applicat ions, and provides an optional, advanced ocd system, no data or instruction caches, and an op tional memory protecti on unit (mpu). java acceleration is not implemented. avr32uc provides three memory interfaces, one high speed bus (hsb) master for instruction fetch, one hsb bus master for data access, and one hsb slave interface allowing other bus masters to access data rams internal to the cpu. keeping data rams internal to the cpu allows fast access to the rams, reduces la tency and guarantees deterministic timing. also, power consumption is reduced by not needing a full hsb bus access for memory accesses. a dedicated data ram interface is provided for communicating with the internal data rams. if an optional mpu is present, all memory acce sses are checked for privilege violations. if an access is attempted to an illega l memory address, the access is aborted and an exception is taken. the following figure displays the contents of avr32uc:
5 32002f?03/2010 avr32 figure 1-1. overview of avr32uc. 1.8 avr32uc cpu revisions three revisions of the avr32uc cpu currently exist: revision 1 implementing revision 1 of the avr32 architecture. revision 2 implementing revision 2 of the avr32 architecture, and with a faster divider. revision 3 implementing revision 3 of the avr3 2 architecture, and with optional floating-point hardware. revision 2 of the avr32uc cpu added the following instructions: movh rd, imm {add, sub, and, or, eor}{cond4}, rd, rx, ry ld.{sb, ub, sh, uh, w}{cond4} rd, rp[disp] st.{b, h, w}{cond4} rp[disp], rs rsub{cond4} rd, imm revision 3 of the avr32uc cpu added the following instructions: avr32uc cpu pipeline instruction memory controller data memory controller high speed bus master mpu high speed bus high speed bus ocd system ocd interface interrupt controller interface high speed bus slave high speed bus data ram interface high speed bus master power/ reset control reset interface cpu local bus master cpu local bus
6 32002f?03/2010 avr32 sscall retss floating-point instructions as described in section 4. on page 40 . revision 3 of the avr32uc cpu added the following system registers: ss_status ss_adrf, ss_adrr, ss_adr0, ss_adr1 ss_sp_sys, ss_sp_app ss_rar, ss_rsr revision 3 of the avr32uc cpu added the following bit in the status register: ss avr32uc cpu revision 2 is fully backward-compatible with revision 1, ie. code compiled for revision 1 is binary-compatible with revision 2 cpus. avr32uc cpu revision 3 is fully backward-compatible with revision 1 and 2, ie. code compiled for revision 1 and 2 is binary-c ompatible with revision 3 cpus. the architecture revision field in the config0 system register identifies which architecture revision is implemented in a specific device. the ?processor and architecture?-chapter of the device datasheet identifies the cpu revision used.
7 32002f?03/2010 avr32 2. programming model this chapter describes the programming model and the set of registers accessible to the user. it also describes the implementation options in avr32uc. 2.1 architectural compatibility avr32uc is fully compatible with the atmel avr32a architecture. avr32uc devices imple- menting both revision 2 and revision 3 of the avr32 architecture exist. refer to the device datasheet or the device?s config0 register to determine which architecture revision the device implements. architecture revision 3 is fully backwards compatible with revision 2, and additionally implements: secure state with associated programming model the automatic clearing of count on compare match is now optional and disabled by setting the nocompres bit in cpucr. 2.2 implementation options 2.2.1 memory protection avr32uc optionally supports an mpu as specified by the avr32 architecture. 2.2.2 java support avr32uc does not implement java hardware acceleration. 2.2.3 floating-point hardware avr32uc optionally supports floating-point hardware implemented as coprocessor instructions. 2.3 register file configuration the avr32a architecture dictates a specific register file implementation, reproduced below. secure state context and secure state system registers are only available in devices implement- ing revision 3 of the avr32 architecture.
8 32002f?03/2010 avr32 figure 2-1. register file in avr32a 2.4 the status register the status register (sr) consists of two halfwords, one upper and one lower, see figure 2-2 on page 8 and figure 2-3 on page 9 . the lower halfword contains the c, z, n, v and q flags, as well as the l and t bits, while the upper halfword contains information about the mode and state the processor executes in. the upper halfword can only be accessed from a privileged mode. figure 2-2. the status register high halfword application bit 0 supervisor bit 31 pc sr in t 0p c fintpc in t 1p c smpc r7 r5 r6 r4 r3 r1 r2 r0 bit 0 bit 31 pc sr r12 in t 0 p c fintpc in t 1 p c smpc r7 r5 r6 r4 r11 r9 r10 r8 r3 r1 r2 r0 in t 0 sp_app sp_sys r12 r11 r9 r10 r8 exception nmi in t 1 in t 2 in t 3 lr lr bit 0 bit 31 pc sr r12 in t 0 p c fintpc in t 1 p c smpc r7 r5 r6 r4 r11 r9 r10 r8 r3 r1 r2 r0 sp_sys lr bit 0 bit 31 pc sr r12 in t 0p c fintpc in t 1p c smpc r7 r5 r6 r4 r11 r9 r10 r8 r3 r1 r2 r0 sp_sys lr bit 0 bit 31 pc sr r12 in t 0p c fintpc in t 1p c smpc r7 r5 r6 r4 r11 r9 r10 r8 r3 r1 r2 r0 sp_sys lr bit 0 bit 31 pc sr r12 in t 0p c fintpc in t 1p c smpc r7 r5 r6 r4 r11 r9 r10 r8 r3 r1 r2 r0 sp_sys lr bit 0 bit 31 pc sr r12 in t 0p c fintpc in t 1p c smpc r7 r5 r6 r4 r11 r9 r10 r8 r3 r1 r2 r0 sp_sys lr bit 0 bit 31 pc sr r12 in t 0p c fintpc in t 1p c smpc r7 r5 r6 r4 r11 r9 r10 r8 r3 r1 r2 r0 sp_sys lr secure bit 0 bit 31 pc sr r12 in t 0p c fintpc in t 1p c smpc r7 r5 r6 r4 r11 r9 r10 r8 r3 r1 r2 r0 sp_sec lr ss_status ss_adrf ss_adrr ss_adr0 ss_adr1 ss_sp_sys ss_sp_app ss_rar ss_rsr bit 31 0 0 0 bit 16 interrupt level 0 mask interrupt level 1 mask interrupt level 3 mask interrupt level 2 mask 1 0 0 0 0 1 1 0 0 0 0 0 0 fe i0m gm m1 - d m0 em i2m dm - m2 lc 1 ss initial value bit name i1m mode bit 0 mode bit 1 - mode bit 2 reserved debug state - i3m reserved exception mask global interrupt mask debug state mask secure state
9 32002f?03/2010 avr32 figure 2-3. the status regist er low halfword ss - secure state this bit is indicates if the processor is executing in the secure state. only implemented in devices implementing revision 3 of the avr32 architecture, set to 0 in older revisions. the bit is initialized in an implementation defined way at reset. refer to section 5. ?secure state? on page 59 for more information. dm - debug state mask if this bit is set, the debug state is masked and cannot be entered. the bit is cleared at reset, and can both be read and written by software. d - debug state the processor is in debug state when this bit is set. the bit is cleared at reset and should only be modified by debug hardware, the breakpoint instruction or the retd instruction. undefined behav- iour may result if the user tries to modify this bit using other mechanisms. m2, m1, m0 - execution mode these bits show the active ex ecution mode. the settings for the different modes are shown in table 2-1 on page 10 . m2 and m1 are cleared by reset while m0 is set so that the processor is in supervisor mode after reset. these bits are modified by hardware when initiating interrupt or exception processing. execution of the scall , rets or rete instructions will also change these bits. undefined behaviour may result if the user tries to modify these bits using the mtsr , ssrf or csrf instructions. if software needs to change these bits, scall , rets or rete should be used, possibly with prior modifications of the stack, to achieve the desired changes in a safe way. refer to the avr32 architecture manual for the behaviour of these instructions, note especially how the stack is modified after their execution. bit 15 bit 0 reserved carry zero sign 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - - - - t - bit name initial value 0 0 l q v n z c - overflow saturation - - - lock reserved scratch
10 32002f?03/2010 avr32 em - exception mask when this bit is set, exceptions are masked. exce ptions are enabled otherwise. the bit is auto- matically set when exception processing is initiated or debug mode is entered. software may clear this bit after performing the necessary meas ures if nested exceptions should be supported. this bit is set at reset. i3m - interrupt level 3 mask when this bit is set, level 3 interrupts are masked. if i3m and gm are cleared, int3 interrupts are enabled. the bit is automatically set when in t3 processing is initiated. software may clear this bit after performing the necessary measures if nested int3s should be supported. this bit is cleared at reset. i2m - interrupt level 2 mask when this bit is set, level 2 interrupts are masked. if i2m and gm are cleared, int2 interrupts are enabled. the bit is automatically set when in t3 or int2 processing is initiated. software may clear this bit after performing the necessary measures if nested int2s should be supported. this bit is cleared at reset. i1m - interrupt level 1 mask when this bit is set, level 1 interrupts are masked. if i1m and gm are cleared, int1 interrupts are enabled. the bit is automatically set when int3 , int2 or int1 processing is initiated. soft- ware may clear this bit after performing the necessary measures if nested int1s should be supported. this bit is cleared at reset. i0m - interrupt level 0 mask when this bit is set, level 0 interrupts are masked. if i0m and gm are cleared, int0 interrupts are enabled. the bit is automatically set when int3, int2, int1 or int0 processing is initiated. software may clear this bit after performing t he necessary measures if nested int0s should be supported. this bit is cleared at reset. gm - global interrupt mask when this bit is set, all interrupts are disabled. this bit overrides i0m, i1m, i2m and i3m. the bit is automatically set when exception processing is initiated, debug mode is entered, or a java trap is taken. this bit is automatically cleared when returning from a java trap. this bit is set after reset. table 2-1. mode bit settings m2 m1 m0 mode 1 1 1 non maskable interrupt 1 1 0 exception 1 0 1 interrupt level 3 1 0 0 interrupt level 2 0 1 1 interrupt level 1 0 1 0 interrupt level 0 0 0 1 supervisor 0 0 0 application
11 32002f?03/2010 avr32 t - scratch bit this bit is not set or cleared implicit by any instruction and the programmer can therefore use this bit as a custom flag to for example signal even ts in the program. this bit is cleared at reset. l - lock flag used by the conditional store in struction. used to support atomical memory access. automati- cally cleared by rete . this bit is cleared after reset. q - saturation flag the saturation flag indicates that a saturating arithmetic operation overflowed. the flag is sticky and once set it has to be manually cleared by a csrf instruction after the desired action has been taken. see the instruction set description for details. v - overflow flag the overflow flag indicates that an arithmetic operation overflowed. see the instruction set description for details. n - negative flag the negative flag is modified by arithmetical and logical operations. see the instruction set description for details. z - zero flag the zero flag indicates a zero result after an arithmetic or logic operation. see the instruction set description for details. c - carry flag the carry flag indicates a carry after an arithmetic or logic operation. see the instruction set description for details. 2.5 system registers the system registers are placed outside of the virtual memory space, and are only accessible using the privileged mfsr and mtsr instructions. some of the system registers can be altered automatically by hardware. the table below lists the system registers specified in avr32uc. the programmer is responsible for maintaining correct sequencing of any instructions following a mtsr instruction. table 2-2. system registers reg # address name function 0 0 sr status register 1 4 evba exception vector base address 2 8 acba application call base address 3 12 cpucr cpu control register 4 16 ecr exception cause register 5 20 rsr_sup unused in avr32uc 6 24 rsr_int0 unused in avr32uc 7 28 rsr_int1 unused in avr32uc
12 32002f?03/2010 avr32 8 32 rsr_int2 unused in avr32uc 9 36 rsr_int3 unused in avr32uc 10 40 rsr_ex unused in avr32uc 11 44 rsr_nmi unused in avr32uc 12 48 rsr_dbg return status register for debug mode 13 52 rar_sup unused in avr32uc 14 56 rar_int0 unused in avr32uc 15 60 rar_int1 unused in avr32uc 16 64 rar_int2 unused in avr32uc 17 68 rar_int3 unused in avr32uc 18 72 rar_ex unused in avr32uc 19 76 rar_nmi unused in avr32uc 20 80 rar_dbg return address register for debug mode 21 84 jecr unused in avr32uc 22 88 josp unused in avr32uc 23 92 java_lv0 unused in avr32uc 24 96 java_lv1 unused in avr32uc 25 100 java_lv2 unused in avr32uc 26 104 java_lv3 unused in avr32uc 27 108 java_lv4 unused in avr32uc 28 112 java_lv5 unused in avr32uc 29 116 java_lv6 unused in avr32uc 30 120 java_lv7 unused in avr32uc 31 124 jtba unused in avr32uc 32 128 jbcr unused in avr32uc 33-63 132-252 reserved reserved for future use 64 256 config0 configuration register 0 65 260 config1 configuration register 1 66 264 count cycle counter register 67 268 compare compare register 68 272 tlbehi unused in avr32uc 69 276 tlbelo unused in avr32uc 70 280 ptbr unused in avr32uc 71 284 tlbear unused in avr32uc 72 288 mmucr unused in avr32uc 73 292 tlbarlo unused in avr32uc table 2-2. system registers (continued) reg # address name function
13 32002f?03/2010 avr32 74 296 tlbarhi unused in avr32uc 75 300 pccnt unused in avr32uc 76 304 pcnt0 unused in avr32uc 77 308 pcnt1 unused in avr32uc 78 312 pccr unused in avr32uc 79 316 bear bus error address register 80 320 mpuar0 mpu address register region 0 81 324 mpuar1 mpu address register region 1 82 328 mpuar2 mpu address register region 2 83 332 mpuar3 mpu address register region 3 84 336 mpuar4 mpu address register region 4 85 340 mpuar5 mpu address register region 5 86 344 mpuar6 mpu address register region 6 87 348 mpuar7 mpu address register region 7 88 352 mpupsr0 mpu privilege select register region 0 89 356 mpupsr1 mpu privilege select register region 1 90 360 mpupsr2 mpu privilege select register region 2 91 364 mpupsr3 mpu privilege select register region 3 92 368 mpupsr4 mpu privilege select register region 4 93 372 mpupsr5 mpu privilege select register region 5 94 376 mpupsr6 mpu privilege select register region 6 95 380 mpupsr7 mpu privilege select register region 7 96 384 mpucra mpu cacheable register a 97 388 mpucrb mpu cacheable register b 98 392 mpubra mpu bufferable register a 99 396 mpubrb mpu bufferable register b 100 400 mpuapra mpu access permission register a 101 404 mpuaprb mpu access permission register b 102 408 mpucr mpu control register 103 412 ss_status secure state status register 104 416 ss_adrf secure state address flash register 105 420 ss_adrr secure stat e address ram register 106 424 ss_adr0 secure state address 0 register 107 428 ss_adr1 secure state address 1 register 108 432 ss_sp_sys secure state st ack pointer system register 109 436 ss_sp_app secure state stac k pointer application register table 2-2. system registers (continued) reg # address name function
14 32002f?03/2010 avr32 sr- status register the status register is mapped into the system regi ster space. this allows it to be loaded into the register file to be modified, or to be stored to memory. the status register is described in detail in section 2.4 ?the status register? on page 8 . evba - exception vector base address this register contains a pointer to the excepti on routines. all exception routines start at this address, or at a defined offset relative to the address. special alignment requirements may apply for evba, depending on the implementation of the interrup t controller. exceptions are described in detail in the avr32 architecture manual. acba - application call base address pointer to the start of a table of function pointers. subroutines can thereby be called by the com- pact acall instruction. this facilitates efficient reuse of code. keeping this pointer as a register facilitates multiple function pointer tables. acba is a full 32 bit register, but the lowest two bits should be written to zero, making acba word aligned. failing to do so may result in erroneous behaviour. cpucr - cpu control register register controlling the configuration and behaviour of the cpu. the following fields are defined: 110 440 ss_rar secure state return address register 111 444 ss_rsr secure state return status register 112-191 448-764 reserved reserved for future use 192-255 768-988 impl implementation defined 248 992 msu_addrhi memory service unit address high register 249 996 msu_addrlo memory service unit address low register 250 1000 msu_length memory service unit length register 251 1004 msu_ctrl memory service unit control register 252 1008 msu_status memory service unit status register 253 1012 msu_data memory service unit data register 254 1016 msu_tail memory service unit tailregister 255 1020 reserved reserved for future use table 2-2. system registers (continued) reg # address name function table 2-3. cpu control register name bit reset description - other - unused. read as 0. should be written as 0. nocomp res 17 0 if set, count is not set on compare match. if cleared, count is cleared on compare match. locen 16 0 local bus enable. must be written to 1 to enable the local bus. any access attempted to the local section when this bit is cleared will result in a bus error.
15 32002f?03/2010 avr32 ecr - exception cause register this register identifies the cause of the most recently executed exception. this information may be used to handle exceptions more efficiently in certain opera ting systems. the register is updated with a value equal to the evba offset of the exception, shifted 2 bit positions to the right. only the 9 lowest bits of the evba offset are considered. as an example, an itlb miss jumps to evba+0x50. the ecr will then be load ed with 0x50>>2 == 0x14. the ecr register is not loaded when an scall , breakpoint or ocd stop cpu exception is taken. note that for inter- rupts, the offset is given by the autovector provided by the interrupt controller. the resulting ecr value may therefore overlap with an ecr val ue used by a regular exception. this can be avoided by choosing the autovector offsets so that no such overlaps occur. rsr_dbg - return status register for debug mode when debug mode is entered, the status register contents of the original mode is automatically saved in this register. when the debug routine is finished, the retd instruction copies the con- tents of rsr_dbg into sr. rar_dbg - return address register for debug mode when debug mode is entered, the program counter contents of the original mode is automati- cally saved in this register. when the debug routine is finished, the retd instruction copies the contents of rar_dbg into pc. config0 / 1 - configuration register 0 / 1 used to describe the processor, its configuration and capabilities. the contents and functionality of these registers is described in detail in section 2.7 ?configuration registers? on page 17 . count - cycle counter register can be used as a general counter to time for example execution time. can also be used together with compare to implement a periodic interrupt for example for an os timer. the con- tents and functionality of this register is described in detail in section 2.6 ?compare and count registers? on page 17 . spl 15:11 16 slave pending limit. the maximum number of clock cycles the slave interface can have a request pending due to the cpu owning the rams. after this period, the cpu will lose arbitrartion for the ram, and the slave access can proceed. cpl 10:6 16 cpu pending limit. the maximum number of clock cycles the cpu can have a request pending due to the slave interface owning the rams. after this period, the slave interface will lose arbitrartion for the ram, and the cpu access can proceed. cop 5:1 8 cpu ownership period. the number of cycles the cpu is guaranteed to own the ram after it has won the arbitration for the ram. no arbitration will be performed during this period. sie 0 1 slave interface enable. if this bit is set, the slave interface is enabled. otherwise, the slave interface is disabled and any slave access will be stalled. table 2-3. cpu control register name bit reset description
16 32002f?03/2010 avr32 compare - cycle counter compare register used together with count to implement a periodic interrupt for example for an os timer. the contents and functionality of this register is described in detail in section 2.6 ?compare and count registers? on page 17 . bear - bus error address register physical address that caused a data bus error. this register is read only. writes are allowed, but are ignored. mpuarn - mpu address register n registers that define the base address and size of the protection regions. refer to the avr32 architecture manual for details. mpupsrn - mpu privilege select register n registers that define which privilege register set to use for the different subregions in each pro- tection region. refer to the avr32 architecture manual for details. mpucra / mpucrb - mpu cacheable register a / b registers that define if the different protection regions are cacheable. refer to the avr32 archi- tecture manual for details. mpubra / mpubrb - mpu bufferable register a / b registers that define if the different protection regions are bufferable. refer to the avr32 archi- tecture manual for details. mpuapra / mpuaprb - mpu access permission register a / b registers that define the access permissions for the different protection regions. refer to the avr32 architecture manual for details. mpucr - mpu control register register that control the operation of the mpu. refer to the avr32 architecture manual for details. ss_status - secure state status register register that can be used to pass status or other information from the secure state to the nonse- cure state. refer to section 5. ?secure state? on page 59 for details. ss_adrf, ss_adrr, ss_adr0, ss_adr1 - secure state ad dress registers registers used to partition memories into a secure and a nonsecure section. the 10 lsbs must always be written to zero. refer to section 5. ?secure state? on page 59 for details. ss_sp_sys, ss_sp_app - secure stat e sp_sys and sp_app registers read-only registers containing the sp _sys and sp_app values. refer to section 5. ?secure state? on page 59 for details. ss_rar, ss_rsr - secure state return ad dress and return status registers contains the address and status register of the sscall instruction that called secure state. also used when returning to nonsecure state with the retss instruction. refer to section 5. ?secure state? on page 59 for details.
17 32002f?03/2010 avr32 msu_addrhi, msu_addrlo, msu_length, msu_ct rl, msu_status, msu_data, msu_tail - memory service unit registers these registers are system register mappings of the memory service unit registers. refer to section 9.8 ?memory service unit? on page 138 for details. 2.6 compare and count registers the count register increments once every cloc k cycle, regardless of pipeline stalls and flushes. the count register can both be read and written. the count register can be used together with the compare register to create a timer with periodic interrupt. the count regis- ter is written to zero upon reset and compare match if the cpucr[nocompres] bit is cleared, otherwise count is not reset on compare match. incrementation of the count register can not be disabled. the count register will incremen t even though a compar e interrupt is pending. the compare register holds a value that the count register is compared against. the com- pare register can both be read and written. when the compare and count registers match, a compare interrupt requ est is generated and coun t is reset to 0. co unt will thereafter con- tinue incrementing in the following clock cycle. the interrupt request is routed out to the interrupt controller, which may forward the request back to the processor as a normal interrupt request at a priority level determined by the interrupt cont roller. writing a value to the compare register clears any pending compare interrupt requests. the compare and exception generation feature is disabled if the compare register contains the value zero. the compare register is written to zero upon reset. count and compare are clocked by a dedicate d clock with the same frequency as the cpu clock. this allows them to operate in some of the sleep modes. they can therefore be used as timers even when the system use sleep modes. consult the clock system documentation for information on which sleep modes count and compare are operational. 2.7 configuration registers configuration registers are used to inform applications and operating systems about the setup and configuration of the processor on which it is running, see figure 2-4 on page 17 . avr32uc implements the following read-only configuration registers. figure 2-4. configuration registers processor id at 0 9 24 31 config0 76 processor revision ar mmut 23 16 15 13 12 10 s immu sz iset 26 31 config1 ilsz 25 20 19 15 16 12 dmmu sz iass 13 dset dlsz 10 9 6 5 dass 3 p o f 5 0 j 4 2 32 d r 1 - 19 20
18 32002f?03/2010 avr32 table 2-4 on page 18 shows the config0 fields. table 2-4. config0 fields name bit description processor id 31:24 specifies the type of processor. this allows the application to distinguish between different processor implementations. reserved 23:20 reserved for future use. processor revision 19:16 specifies the revision of the processor implementation. at 1 5 : 1 3 architecture type value semantic 0 avr32a 1 unused in avr32uc other reserved ar 12:10 architecture revision value semantic 0 unused in avr32uc 1 revision 1 2 revision 2 3 revision 3 other reserved mmut 9:7 mmu type value semantic 0 none, using direct mapping and no segmentation 1 unused in avr32uc 2 unused in avr32uc 3 memory protection unit other reserved f6 floating-point unit implemented value semantic 0 no fpu implemented 1 floating-point unit implemented j5 java extension implemented value semantic 0 no java extension implemented 1 unused in avr32uc p4 performance counters implemented value semantic 0 no performance counters implemented 1 unused in avr32uc
19 32002f?03/2010 avr32 table 2-5 on page 19 shows the config1 fields. o3 on-chip debug implemented value semantic 0 no ocd implemented 1 ocd implemented s2 simd instructions implemented value semantic 0 no simd instructions 1 unused in avr32uc d1 dsp instructions implemented value semantic 0 unused in avr32uc 1 dsp instructions implemented r0 memory read-modify-write instructions implemented value semantic 0 unused in avr32uc 1 rmw instructions implemented table 2-5. config1 fields name bit description immu sz 31:26 unused in avr32uc dmmu sz 25:20 specifies the number of mpu entries. iset 19:16 unused in avr32uc ilsz 15:13 unused in avr32uc iass 12:10 unused in avr32uc dset 9:6 unused in avr32uc dlsz 5:3 unused in avr32uc dass 2:0 unused in avr32uc table 2-4. config0 fields (continued) name bit description
20 32002f?03/2010 avr32 3. pipeline 3.1 overview avr32uc is a pipelined processor with three pipeline stages: if, id and ex. all instructions are issued and complete in order. some instructions may require several iterations through the ex stage in order to complete. the following figure shows an overview of the avr32uc pipeline stages. figure 3-1. the avr32uc pipeline stages. the follwing abbrevia tions are used in the figure: if - instruction fetch id - instruction decode ex - instruction execute mul - multiplier alu - arithmetic-logic unit ls - load/store unit 3.2 prefetch unit the prefetch unit comprises the if pipestage, and is responsible for feeding instructions to the decode unit. the prefetch unit fetches 32 bits at a time from the instruction memory interface and places them in a fifo prefetch buffer. at the same time, one instruction, either risc extended or compact, is fed to the decode stage. 3.3 decode unit the decode unit generates the necessary signals in order for the instruction to execute correctly. the id stage accepts one instruction each clock cy cle from the prefetch unit. this instruction is then decoded, and control signals and register file addresses are generated. if the instruction cannot be decoded, an ille gal instruction or unimp lemented instruction exce ption is issued. the id stage also contains a state machine re quired for controlling multicycle instructions. the id stage performs the remapping of register file addresses from logical to physical addresses. this is used for remapping the stack pointer register into the sp_app or sp_sys registers. if id alu mul r egfile write prefetch unit decode unit alu unit m ultiply unit load-store unit ls regfile read
21 32002f?03/2010 avr32 3.4 ex pipeline stage the execute (ex) pipeline stage performs register file reads, operations on registers and mem- ory, and register file writes. 3.4.1 alu section the alu pipeline performs most of the data manipulation instructions, like arithmetical and logi- cal operations. the alu sta ge performs the following tasks: target address calculation and condition check for change-of-flow instructions. condition code checking for conditional instructions. address calculation for memory accesses writeback address calculation for the ls pipeline. all flag setting for arithmetic al and logical instructions. the saturation needed by satadd and satsub . the operation needed by satrnds , satrndu , sats and satu . signed and unsigned division 3.4.2 multiply section all multiply instructions execute in the multiply section. this section implements a 32 by 32 mul- tiplier array, and 16x16, 32x16 and 32x32 multiplic ations and multiply-accumulates therefore have an issue latency of one cycle. multiplication of 32 by 32 bits to a 64-bit result require two iterations through the multiplier array, and therefore needs several cycles to complete. this will stall the multiply pipeline unt il the instruction is complete. a special accumulator cache is im plemented in the mul section. this cache saves the multiply- accumulate result in dedi cated registers in the mul section, as well as writing them back to the register file. this allows subsequent mac instructions to read the accumulator value from the cache, instead of from the regist er file. this will speed up mac operations by one clock cycle. if a mac instruction targets a register not found in the cache, one clock cycle is added to the mac operation, loading the accumulator value from the register file into the cache. in the next cycle, the mac operation is restarted automatically by hardware. if an instruction, like an add, mul or load, is executed with ta rget address equal to that of a va lid cached register, the instruction will update the cache. the accumulator cache can hold one doubleword ac cumulator value, or one word accumulator value. hardware ensures that the accumulator cache is kept consistent. if another pipeline sec- tion writes to one of the registers kept in the accumulator cache, the cache is updated. the cache is automatically invalidated after reset. 3.4.3 load-store section the load-store (ls) pipeline is able to read or write one register per clock cycle. the address is calculated by the alu section. thereafter the address is passed on to the ls section and output to the memory interface, together with the data to write if the access is a write. if the access is a read, the read data is returned from the memory interface in the same cycle. if the read data requires typecasting or other manipulation like performed by ldins or ldswp , this manipulation is performed in the same cycle. any load or store multiple registers are decoded by the id stage and passed on to the ex stage as a series of single load or store word operations.
22 32002f?03/2010 avr32 the read-modify-write instructions memc , mems and memt are performed as a non-interruptable sequence of read from and write to memory. the load-store section generates the control sig- nals required to perform this sequence. this sequ ence takes several clock cycles, so any following instructions requiring the use of the l oad-store section must stall until the sequence is finished. following instructions th at do not use the load-store sectio n will not have to stall even if the sequence has not finished. some memory operations to slow memories, such as memories on the hsb bus, may require several clock cycles to perform. if required, t he cpu pipeline will stall as long as necessary in order to perform the memory access. 3.5 support for unaligned addresses all memory accesses must be performed with the correct alignment according to the data size. the only exception to this is doubleword access es, which are performed as two word accesses, and therefore can be word-aligned. any ot her unaligned memory ac cess will cause an data address exception. instruction fetches must be ha lfword aligned. any other alig nment will cause an instruction address exception. 3.6 forwarding hardware and hazard detection since the register file is read and written in the same pipeline stage, no hazards can occur, and no forwarding is necessary. the programmer does not need to take any special considerations regarding data hazards when writing code. 3.7 event handling due to various reasons, the cpu may be required to abort normal program execution in order to handle special, high-priority events. when handling of these events is complete, normal program execution can be resumed. traditionally, events that are generated internally in the cpu are called exceptions, while events generated by sources external to the cpu are called interrupts. the possible sources of events are listed in table 3-4 on page 28 . the avr32 has a powerful event handling scheme. the different event sources, like illegal opcode and external interrupt requests, have different priority levels, ensuring a well-defined behaviour when multiple events are received simu ltaneously. additionally, pending events of a higher priority class may preempt handling of ongoing events of a lower priority class. when an event occurs, the execution of the instruction stream is halted, and execution control is passed to an event handler at an address specified in table 3-4 on page 28 . most of the han- dlers are placed sequentially in the code space starting at the address specified by evba, with four bytes between each handler. this gives am ple space for a jump instruction to be placed there, jumping to the event rout ine itself. a few critical handle rs have larger spacing between them, allowing the entire event routine to be placed directly at the address specified by the evba-relative offset generated by hardware. all external interrupt sources have autovectored interrupt service routine (isr) addresses. this allows the interrupt controller to directly specify the isr address as an address relative to evba. the autovector offset has 14 address bits, giv- ing an offset of maximum 16384 bytes. the target address of the event handler is calculated as (evba | event_handler_offset), not (evba + even t_handler_offset), so evba and exception code segments must be set up appropriately.
23 32002f?03/2010 avr32 the same mechanisms are used to service all different types of events, including external inter- rupt requests, yielding a uniform event handling scheme. each pipeline stage has a pipeline register that holds the exception requests associated with the instruction in that pipeline stage. this allows the exception request to follow the contaminated instruction through the pipeline. exceptions are detected in two different pipeline stages. the ex stage detects all data-address related exceptions (dtlb protection and data address). all other exceptions, including interrupts, are detected in the id stage. when an exception is detected in ex, the ex stage and all upstream stages are flushed. generally, all exceptions, including breakpoint, have the failing instruction as restart address. this allows a fixup exception routine to correct the error and restart the instruction. interrupts (int0-3, nmi) have the address of the first non-completed instruction as restart address. 3.7.1 exceptions and interrupt requests when an event other than scall or debug request is received by the core, the following actions are performed atomically: 1. the pending event will no t be accepted if it is masked. the i3m, i2m, i1m, i0m, em and gm bits in the status register are used to mask different events. not all events can be masked. a few critical events (nmi, unrecove rable exception, tlb multiple hit and bus error) can not be masked. when an event is accepted, hardware automatically sets the mask bits corresponding to all sources with e qual or lower priority. this inhibits accep- tance of other events of the same or lower priority, except for the critical events listed above. software may choose to clear some or all of these bits after saving the neces- sary state if other priority schemes are desire d. it is the event source?s responsibility to ensure that their events are left pending until accepted by the cpu. 2. when a request is accepted, the status register and program counter of the current context is stored to the system stack. if the event is an int0, int1, int2 or int3, regis- ters r8-r12 and lr are also automatically stored to stack. storing the status register ensures that the core is returned to the previous execution mode when the current event handling is completed. when exceptions occur, both the em and gm bits are set, and the application may manually enable nested exceptions if desired by clearing the appropriate bit. each exception handler has a dedicated handler address, and this address uniquely identifies the exception source. 3. the mode bits are set to reflect the priority of the accepted event, and the correct regis- ter file bank is selected. the address of the event handler, as shown in table 3-4, is loaded into the program counter. the execution of the event handler routine then continues from the effective address calculated. the rete instruction signals the end of the event. when encountered, the return status register and return address register are popped from the system stack and restored to the status reg- ister and program counter. if the rete instruction returns from int0, int1, int2 or int3, registers r8-r12 and lr are also popped from the system stack. the restored status register contains information allowing the core to resume operation in the previous execution mode. this concludes the event handling. note that event priorities are only used to determine which event handler to call first when multi- ple events are received simultaneously. once control is passed on to the event handler, handling of pending and lower priority events may be initiated if not masked. for instance, it is possible to make a superviso r call (scall) from an interrupt level 0 handler, even though the priority of a supervisor call event is lower than the active interrupt level 0 event.
24 32002f?03/2010 avr32 3.7.2 supervisor calls the avr32 instruction set provides a supervisor mode call instruction. the scall instruction is designed so that privileged routines can be called from any context. this facilitates sharing of code between different execution modes. the scall mechanism is designed so that a minimal execution cycle overhead is experienced when performing supervisor routine calls from time- critical event handlers. the scall instruction behaves differently depending on which mode it is called from. the behav- iour is detailed in the instruction se t reference. in order to allow the scall routine to return to the correct context, a return from supervisor call instruction, rets , is implemented. in the avr32a microarchitecture, scall and rets uses the system stack to store the return address and the sta- tus register. 3.7.3 debug requests the avr32 architecture defines a dedicated debug mode. when a debug request is received by the core, debug mode is entered. entry into debug mode can be masked by the dm bit in the status register. upon entry into debug mode, hardware sets the sr[d] bit and jumps to the debug exception handler. by default, debug mode executes in the exception context, but with dedicated return address register and return status register. these dedicated registers remove the need for storing th is data to the system stack, thereby improving debuggability. debug mode is exited by executing the retd instruction. this return s to the previous context. 3.8 special concerns 3.8.1 system stack event handling in avr32uc, like in all avr32a architectures, uses the system stack pointed to by the system stack pointer, sp_sys, for pushing and popping r8 -r12, lr, status register and return address. since exception code may be ti ming-critical, sp_sys should point to memory addresses in the iram section, since the timing of accesses to this memory section is both fast and deterministic. the user must also make sure that the system stack is large enough so that any event is able to push the required registers to stack. if the system stack is full, and an event occurs, the system will enter an undefined state. 3.8.2 clearing of pending interrupt requests when an interrupt request is accepted by the cpu, the interrupt handler will eventually be called. the interrupt handler is responsible for performing the required actions so that the requesting module disasserts the interrupt request before the interrupt routine is exited with rete . failing to do so will cause t he interrupt handler to be re-entered after the rete instruction has been executed, since the interrupt request is still active. different interrupt sources have differ- ent ways of disasserting requests, for example reading an interrupt cause register or writing to specific control registers. refer to the module -specific documentation for information on how to disassert interrupt requests. disasserting an interrupt request often requires that a bus access is performed to the requesting module. an example of such an access is to read an interrupt caus e register. there will be a latency from the execution of the load or store instruction that is to disassert the interrupt request and the actual disassertion of the request. th is latency can be caused by the bus system and internal latencies in the interrupting module. it is important that the programmer makes sure that the interrupt request has actually been disasserted before returning from the interrupt with rete .
25 32002f?03/2010 avr32 this can usually be ensured by scheduling the code sequence disasserting the interrupt request in such a way that one can be certain that the interrupt request has actually been disasserted before the rete instruction is executed. code 3-1. clearing irqs using code scheduling the mechanisms and timing required for disasserting an interrupt request from a module is spe- cific to different modules. usually, the request is disasserted within a few clock cycles after the load or store instruction has been received by the module. in this case, a simple way of making sure that the request has actually been di sasserted is to use a data memory barrier ( ?data mem- ory barriers? on page 64 ). the dmb will block the cpu pipeline until the interrupt request has been disasserted. at this point, the rete instruction can safely be executed. code 3-2. clearing irqs using da ta memory barriers the programmer should consult the data sheets fo r the different peripheral modules to check if special timings or concerns related to disasserting of interrupt requests apply to the specific module. 3.8.3 masking interrupt requests in peripheral modules handling an interrupt request involves several operations like pushing of registers to stack and takes several clock cycles. the required operati ons are controlled by sequencing logic in hard- ware. this sequencing hardware does not permit that an asserted interrupt request is disasserted while it is in the proces s of handling this interrupt request. hardware makes sure that manipulation of the gm and ixm bits in sreg can be performed safely at all times using the mtsr , csrf and ssrf instructions. the programmer does not need to take any special concerns when issuing one of these instructions. all hardware connected to the cpu is implemented in such a way that once an interrupt request is asserted by the hardware, it can only be di sasserted by explicit ac tions by the programmer. // using scheduling of instructions in the irq handler to make sure that the // request has been disasserted before returning from the handler. // assume that the irq is cleared by reading periph_intcause, r0 points to // this register. irq_handler: ld.w r12, r0[0] // clear the irq rete // using data memory barriers in the irq handler to make sure that the // request has been disasserted before returning from the handler // assume that the irq is cleared by writing a bitmask to periph_intclear. // r0 points to this register, r1 contains the correct bitmask. irq_handler: st.w r0[0], r1 ld.w r12, r0[0] // data memory barrier rete
26 32002f?03/2010 avr32 many peripheral modules that are able to assert interrupt requests have control registers or other means of masking one or more of its in terrupt requests. for example, a usart can con- tain an interrupt mask register with indivi dual bits for masking ?tx ready? and ?rx ready? interrupts. writing to such a mask register may cause a pending interrupt request from that mod- ule to be disasserted. the programmer must at all times make sure that an action that will disassert inte rrupts at the interrupt source is not performed if it is possible that the interrupt sequencing hardware is in the processing of handling the interrupt request that will be disasserted by the action. it is safe to perform such an action if one of the following is true: the sreg gm or ixm bit corresponding to the priority of the interrupt request to be masked is set before the action is performed. it can be guaranteed that the interrupt request being masked by the action is disasserted when the action is initiated and being performed. code 3-3. masking irqs in a peripheral module which may assert an irq at any time if the interrupt request is disasserted during the critical clock cycles where the sequencing hard- ware is active handling this interrupt request, the cpu may enter an unpredictable state. 3.9 entry points for events several different event handler entry points exists. in avr32uc, the reset address is 0x8000_0000. this places the reset address in the boot flash memory area. tlb miss exceptions and scall have a dedicated space relative to evba where their event han- dler can be placed. this speeds up execution by removing the need for a jump instruction placed at the program address jumped to by the event hardware. all other exceptions have a dedicated event routine entry point located relative to evba. the handler routine address identifies the exception source directly. avr32uc uses the itlb and dtlb protection exc eptions to signal a mp u protection violation. itlb and dtlb miss exceptions are used to signal that an access address did not map to any of the entries in the mpu. tlb multiple hit exception indicates that an access address did map to multiple tlb entries, signalling an error. all external interrupt r equests have entry point s located at an offset relative to evba. this autovector offset is specified by an external interrupt controller. the programmer must make sure that none of the autovector offsets interfer e with the placement of other code. the autovec- tor offset has 14 address bits, giving an offset of maximum 16384 bytes. special considerations should be made when loading evba with a po inter. due to security con- siderations, the event handlers should be located in non-writeable flash memory, or optionally in a privileged memory protection region if an mpu is present. // masking tx_ready irq in a peripheral by setting the txmask bit in the // irqmask register of the peripheral. // could alternatively mask the sreg ixm bit associated with the irq source disassert_periph_tx_irq: ssrf avr32_sreg_gm mems periph_irqmask, periph_txmask csrf avr32_sreg_gm
27 32002f?03/2010 avr32 if several events occur on the same instruction, they are handled in a prioritized way. the priority ordering is presented in table 3-4. if events occur on several instructions at different locations in the pipeline, the events on the oldest instruction are always handled before any events on any younger instruction, even if the younger instructi on has events of higher priority than the oldest instruction. an instruction b is younger than an in struction a if it was sent down the pipeline later than a. the addresses and priority of simultaneous events are shown in table 3-4 on page 28 . some of the exceptions are unused in avr32uc since it has no mmu or coprocessor interface. the interrupt system requires that an interrupt controller is presen t outside the co re in order to prioritize requests and generate a correct offset if more than one interrupt source exists for each priority level. an interrupt controller generating different offsets depending on interrupt request source is referred to as autovectoring. note that the interrupt controller should generate autovector addresses that do not conflict with addresses in use by other events or regular pro- gram code. the addresses of the interrupt routines are calculated by adding the address on the autovector offset bus to the value of the exception vector base address (evba). the int0, int1, int2, int3, and nmi signals indicate the priority of the pending interrupt. int0 has the lowest priority, and nmi the highest priority of the interrupts.
28 32002f?03/2010 avr32 3.9.1 description of events 3.9.1.1 reset exception the reset exception is generated when the reset input line to the cpu is asserted. the reset exception can not be masked by any bit. the reset exception resets all synchronous elements and registers in the cpu pipeline to their default value, and starts execution of instructions at address 0x8000_0000. sr = reset_value_of_sreg; table 3-4. priority and handler addresses for events priority handler address name event source stored return address 1 0x8000_0000 reset external input undefined 2 provided by ocd system ocd stop cpu ocd system first non-compl eted instruction 3 evba+0x00 unrecoverable exception int ernal pc of offending instruction 4 evba+0x04 tlb multiple hit mpu pc of offending instruction 5 evba+0x08 bus error data fetch data bu s first non-completed instruction 6 evba+0x0c bus error instruction fetch dat a bus first non-completed instruction 7 evba+0x10 nmi external input first non-completed instruction 8 autovectored interrupt 3 request external input first non-completed instruction 9 autovectored interrupt 2 request external input first non-completed instruction 10 autovectored interrupt 1 request external input first non-completed instruction 11 autovectored interrupt 0 request external input first non-completed instruction 12 evba+0x14 instruction address cp u pc of offending instruction 13 evba+0x50 itlb miss mpu pc of offending instruction 14 evba+0x18 itlb protection mpu pc of offending instruction 15 evba+0x1c breakpoint ocd system firs t non-completed instruction 16 evba+0x20 illegal opcode instructio n pc of offending instruction 17 evba+0x24 unimplemented instruction instr uction pc of offending instruction 18 evba+0x28 privilege violation instruc tion pc of offending instruction 19 evba+0x2c floating-point unused 20 evba+0x30 coprocessor absent coproces sor pc of offending instruction 21 evba+0x100 supervisor call instru ction pc(supervisor call) +2 22 evba+0x34 data address (read) cp u pc of offending instruction 23 evba+0x38 data address (write) cpu pc of offending instruction 24 evba+0x60 dtlb miss (read) mpu pc of offending instruction 25 evba+0x70 dtlb miss (write) mpu pc of offending instruction 26 evba+0x3c dtlb protection (read) mpu pc of offending instruction 27 evba+0x40 dtlb protection (write) m pu pc of offending instruction 28 evba+0x44 dtlb modified unused
29 32002f?03/2010 avr32 pc = 0x8000_0000; all other system registers are reset to their reset value, which may or may not be defined. refer to the programming model chapter for details. 3.9.1.2 ocd stop cpu exception the ocd stop cpu exception is generated when the ocd stop cpu input line to the cpu is asserted. the ocd stop cpu exception can not be masked by any bit. this exception is identi- cal to a non-maskable, high priority breakpoint . any subsequent operation is controlled by the ocd hardware. the ocd hardware will take control over the cpu an d start to feed instructions directly into the pipeline. rsr_dbg = sr; rar_dbg = pc; sr[m2:m0] = b?110; sr[d] = 1; sr[dm] = 1; sr[em] = 1; sr[gm] = 1; 3.9.1.3 unrecoverable exception the unrecoverable exception is generated when an exception request is issued when the exception mask (em) bit in the status register is asserted. the unrecoverable exception can not be masked by any bit. the unrecoverable exception is generated when a condition has occurred that the hardwa re cannot handle. the system will in mo st cases have to be restarted if this condition occurs. *(--sp sys ) = pc of offending instruction; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x00; 3.9.1.4 tlb multiple hit exception the tlb multiple hit exception is generated when an access hits in mult iple mpu regions. this is usually caused by programming error. used only if an mpu is present. *(--sp sys ) = pc of offending instruction; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x04; 3.9.1.5 bus error exception on data access the bus error on data access exception is generated when the data bus detects an error condi- tion. this exception is caused by events unrelated to the instruction stream, or by data written to the cache write-buffers many cycles ago. theref ore, execution can not be resumed in a safe way after this exception. the return address placed on stack is unrelated to the operation that
30 32002f?03/2010 avr32 caused the exception. the exce ption handler is responsible for performing the appropriate action. *(--sp sys ) = pc of first non-issued instruction; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x08; bear = failing address 3.9.1.6 bus error exception on instruction fetch the bus error on instruction fetch exception is generated when the data bus detects an error condition. this exception is caus ed by events related to the instruction stream. therefore, exe- cution can be restarted in a safe way after th is exception, assuming that the condition that caused the bus error is dealt with. *(--sp sys ) = pc of first non-issued instruction; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x0c; 3.9.1.7 nmi exception the nmi exception is generated when the nmi input line to the core is asserted. the nmi excep- tion can not be masked by the sr[gm] bit. however, the core ignores the nmi input line when processing an nmi exception (the sr[m2:m0] bits are b?111). th is guarantees serial execution of nmi exceptions, and simplifies the nmi hardware and software mechanisms. since the nmi exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. after finishing the nmi exception routine, execution should continue at the instruction following the last completed instruction in the instruction stream. *(--sp sys ) = pc of first noncompleted instruction; *(--sp sys ) = sr; sr[m2:m0] = b?111; sr[em] = 1; sr[gm] = 1; pc = evba | 0x10; 3.9.1.8 int3 exception the int3 exception is generated when the int3 input line to the core is asserted. the int3 exception can be masked by the sr[gm] bit, and t he sr[i3m] bit. hardware automatically sets the sr[i3m] bit when accepting an int3 exception, inhibiting new int3 requests when process- ing an int3 request. the int3 exception handler address is calculated by adding evba to an interrupt vector offset specified by an interrupt controller outside the core. the interrupt controller is responsible for providing the correct offset.
31 32002f?03/2010 avr32 since the int3 exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. after finishing the int3 exception routine, execution should continue at the instruction following the last completed inst ruction in the instruction stream. *(--sp sys ) = r8; *(--sp sys ) = r9; *(--sp sys ) = r10; *(--sp sys ) = r11; *(--sp sys ) = r12; *(--sp sys ) = lr; *(--sp sys ) = pc of first noncompleted instruction; *(--sp sys ) = sr; sr[m2:m0] = b?101; sr[i3m] = 1; sr[i2m] = 1; sr[i1m] = 1; sr[i0m] = 1; pc = evba | interrupt_vector_offset; 3.9.1.9 int2 exception the int2 exception is generated when the int2 input line to the core is asserted. the int2 exception can be masked by the sr[gm] bit, and t he sr[i2m] bit. hardware automatically sets the sr[i2m] bit when accepting an int2 exception, inhibiting new int2 requests when process- ing an int2 request. the int2 exception handler address is calculated by adding evba to an interrupt vector offset specified by an interrupt controller outside the core. the interrupt controller is responsible for providing the correct offset. since the int2 exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. after finishing the int2 exception routine, execution should continue at the instruction following the last completed inst ruction in the instruction stream. *(--sp sys ) = r8; *(--sp sys ) = r9; *(--sp sys ) = r10; *(--sp sys ) = r11; *(--sp sys ) = r12; *(--sp sys ) = lr; *(--sp sys ) = pc of first noncompleted instruction; *(--sp sys ) = sr; sr[m2:m0] = b?100; sr[i2m] = 1; sr[i1m] = 1; sr[i0m] = 1; pc = evba | interrupt_vector_offset; 3.9.1.10 int1 exception the int1 exception is generated when the int1 input line to the core is asserted. the int1 exception can be masked by the sr[gm] bit, and t he sr[i1m] bit. hardware automatically sets
32 32002f?03/2010 avr32 the sr[i1m] bit when accepting an int1 exception, inhibiting new int1 requests when process- ing an int1 request. the int1 exception handler address is calculated by adding evba to an interrupt vector offset specified by an interrupt controller outside the core. the interrupt controller is responsible for providing the correct offset. since the int1 exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. after finishing the int1 exception routine, execution should continue at the instruction following the last completed inst ruction in the instruction stream. *(--sp sys ) = r8; *(--sp sys ) = r9; *(--sp sys ) = r10; *(--sp sys ) = r11; *(--sp sys ) = r12; *(--sp sys ) = lr; *(--sp sys ) = pc of first noncompleted instruction; *(--sp sys ) = sr; sr[m2:m0] = b?011; sr[i1m] = 1; sr[i0m] = 1; pc = evba | interrupt_vector_offset; 3.9.1.11 int0 exception the int0 exception is generated when the int0 input line to the core is asserted. the int0 exception can be masked by the sr[gm] bit, and t he sr[i0m] bit. hardware automatically sets the sr[i0m] bit when accepting an int0 exception, inhibiting new int0 requests when process- ing an int0 request. the int0 exception handler address is calculated by adding evba to an interrupt vector offset specified by an interrupt controller outside the core. the interrupt controller is responsible for providing the correct offset. since the int0 exception is unrelated to the instruction stream, the instructions in the pipeline are allowed to complete. after finishing the int0 exception routine, execution should continue at the instruction following the last completed inst ruction in the instruction stream. *(--sp sys ) = r8; *(--sp sys ) = r9; *(--sp sys ) = r10; *(--sp sys ) = r11; *(--sp sys ) = r12; *(--sp sys ) = lr; *(--sp sys ) = pc of first noncompleted instruction; *(--sp sys ) = sr; sr[m2:m0] = b?010; sr[i0m] = 1; pc = evba | interrupt_vector_offset;
33 32002f?03/2010 avr32 3.9.1.12 instruction address exception the instruction address error exception is generated if the generated instruction memory address has an illegal alignment. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x14; 3.9.1.13 itlb miss exception the itlb miss exception is generated when the mpu is enabled and the instruction memory access does not hit in any regions. used only if an mpu is present. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x50; 3.9.1.14 itlb protection exception the itlb protection exception is generated when the instruction memory access violates the access rights specified by the protection region in which the address lies. used only if an mpu is present. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x18; 3.9.1.15 breakpoint exception the breakpoint exception is issued when the ocd breakpoint input line to the cpu is aseerted, and sreg[dm] is cleared. when entering the exception routine, rar_dbg points to the breakpoint instruction, and the cpu will enter debug mode. an external debugger can optionally assume control of the cpu when the breakpoint exception is executed. the d ebugger can then issue individual instructions to be executed in debug mode. debug mode is exited with the retd instruction. this passes con- trol from the debugger back to the cpu, resuming normal execution. rsr_dbg = sr; rar_dbg = pc; sr[m2:m0] = b?110; sr[d] = 1; sr[dm] = 1; sr[em] = 1; sr[gm] = 1;
34 32002f?03/2010 avr32 pc = evba | 0x1c; 3.9.1.16 illegal opcode this exception is issued when the core fetches an unknown instruction, or when a coprocessor instruction is not acknowledged. when entering the exception routine, the return address on stack points to the instruction that caused the exception. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x20; 3.9.1.17 unimplemented instruction this exception is issued when the core fetches an instruction supported by the instruction set but not by the current implementation. this allows software implementations of unimplemented instructions. when entering the exception routine, the return address on stack points to the instruction that caused the exception. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x24; table 3-5. list of unimplemented instructions. privileged instructions comment all simd instructions no simd implemented coprocessor instructions adressing unimplemented coprocessors cache - perform cache operation no cache implemented incjosp - increment java stack pointer no java implemented popjc - pop java context no java implemented pushjc - push java context no java implemented retj- return from java mode no java implemented tlbr - read addressed tlb entry into tlbehi and tlbelo no mmu present tlbw - write tlb entry registers into tlb no mmu present tlbs - search tlb for entry matching tlbehi[vpn] no mmu present
35 32002f?03/2010 avr32 3.9.1.18 data read address exception the data read address error exception is generated if the address of a data memory read has an illegal alignment. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x34; 3.9.1.19 data write address exception the data write address error exception is generated if the address of a data memory write has an illegal alignment. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x38; 3.9.1.20 dtlb read miss exception the dtlb read miss exception is generated when the mpu is enabled and the data memory read access does not hit in any regions. used only if an mpu is present. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x60; 3.9.1.21 dtlb write miss exception the dtlb write miss exception is generated when the mpu is enabled and the data memory write access does not hit in any regions. used only if an mpu is present. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x70; 3.9.1.22 dtlb read protection exception the dtlb protection exception is generated when the data memory read violates the access rights specified by the protection region in which the address lies. used only if an mpu is present. *(--sp sys ) = pc; *(--sp sys ) = sr;
36 32002f?03/2010 avr32 sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x3c; 3.9.1.23 dtlb write protection exception the dtlb protection exception is generated when the data memory write violates the access rights specified by the protection region in which the address lies. used only if an mpu is present. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x40; 3.9.1.24 privilege violation exception if the application tries to execute privileged instru ctions, this exception is issued. the complete list of priveleged inst ructions is shown in table 3-6 on page 36 . when entering the exception routine, the address of the instruction that caused the exception is stacked as the return address. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x28; 3.9.1.25 dtlb modified exception unused in avr32uc, since it has no mmu. table 3-6. list of instructions which can only execute in privileged modes. privileged instructions comment csrf - clear status register flag privileged onl y when accessing upper half of status register mtsr - move to system register mfsr - move from system register mtdr - move to debug register mfdr - move from debug register rete- return from exception rets - return from supervisor call retd - return from debug mode sleep - sleep ssrf - set status register flag privileged only when accessing upper half of status register
37 32002f?03/2010 avr32 3.9.1.26 floating-point exception unused in avr32uc. 3.9.1.27 coprocessor absent exception the coprocessor absent except ion is generated when a nonexisting coprocessor is addressed by a coprocessor instruction. used only if one or more coprocessors are present. executing coprocessor instructions in systems with no coprocessors results in an unimplemented instruc- tion exception instead. *(--sp sys ) = pc; *(--sp sys ) = sr; sr[m2:m0] = b?110; sr[em] = 1; sr[gm] = 1; pc = evba | 0x30; 3.9.1.28 supervisor call supervisor calls are signalled by the application code executing a supervisor call ( scall ) instruc- tion. the scall instruction behaves differently depending on which context it is called from. this allows scall to be called from other contexts than application. when the exception routine is finished, execution continues at the instruction following scall . the rets instruction is used to return from supervisor calls. if ( sr[m2:m0] == {b?000 or b?001} ) *(--sp sys ) = pc; *(--sp sys ) = sr; pc evba | 0x100; sr[m2:m0] b?001; else lr pc + 2; pc evba | 0x100; 3.10 interrupt latencies the following features in avr32uc ensure low and deterministic interrupt latency: four different interrupt levels and an nmi ensures that the user can efficiently prioritize the interrupt sources. long-running instructions such as ldm , stm , pushm , popm , divs and divu will be aborted if an interrupt request is received. the slowest instruction that can not be aborted by a pending interrupt has a worst case issue latency of 5 cycles. this imp lies that an interrupt request will need to wait at most 5 cycles for an instruct ion to complete. the fast est instructions need only a single cycle to complete. interrupts are autovectored, allowing the cpu to jump directly to the interrupt handler. when an interrupt of level m is received, the cp u will start stacking register file registers, return address and status regist er. after this stacki ng is performed, t he cpu will jump to the autovector address of the interrupt of level m. if an interrupt of level n, where n > m, is received during this stacking, the cpu will jump to the autovector address of the interrupt of level n, not the autovector address of the original interrupt.
38 32002f?03/2010 avr32 note that the overall system latency from an interrupt request is signaled to the request is being handled depends on a number of things in addition to the latency through the cpu. the latency through the interrupt controller will affect interrupt latency for a ll peripheral inte rrupt requests and the bus matrix, code and data memories will affect overall responsiveness. 3.10.1 maximum interrupt latency the maximum cpu interrupt latency can be calculated as follows: 3.10.2 minimum interrupt latency the minimum cpu interrupt latency of an interrupt request of level m will occur when the cpu is in the process of stacking the registers and return address associated with an interrupt request of level n, where n < m. if the le vel m interrupt request arrives just as the cpu is about to jump to the autovector address for the interrupt of level n, the cpu will jump directly to the autovector address of the latest arriving interrupt. in this case, the minimum interrupt latency is as follows: assuming that the interrupt request arrives when the cpu is in the process of executing program code, the minimum interrupt latency can be calculated as follows: 3.11 nmi latency non-maskable interrupts (nmi) behave similarly to interrupts, except that they do not automati- cally push register file registers on the stack. nmi can, similar to interrupts, abort long-running instructions. table 3-7. maximum interrupt latency source delay wait for the slowest instruction to complete 6 stack register file registers, return a ddress and status register, and jump to autovector target 10 wait for autovector target instruction to be fetched 1 total 17 table 3-8. minimum interrupt latency - higher priority interrupt preempts lower priority interrupt source delay jump to autovector target 1 wait for autovector target instruction to be fetched 1 total 2 table 3-9. minimum interrupt latency - interrupt received when executing program code source delay wait for the fastest instruction to complete 1 stack register file registers, return a ddress and status register, and jump to autovector target 10 wait for autovector target instruction to be fetched 1 total 12
39 32002f?03/2010 avr32 the maximum nmi latency can be calculated as follows: table 3-10. maximum nmi latency source delay wait for the slowest instruction to complete 6 stack return address and status register, and jump to autovector target 4 wait for autovector target instruction to be fetched 1 total 11
40 32002f?03/2010 avr32 4. floating point hardware newer versions of uc3 cpu introduced optional floating-point hardware performing 32-bit float- ing-point operations. in structions controlling th is hardware are mapped into the coprocessor instruction space, addressed as coprocessor 0. the config0 system register f bit indicates if floating-point hardware is present on a specific avr32 device. the floating point hardware reads operands and pl aces results in the same register file as the traditional avr32 instructions. floating-point compare updates the flags in the avr32 status register, so that the regular avr32 branch inst ructions can be used directly after a floating- point compare. the floating-point hardware consists of a fused multiply-accumulate unit, performing as a single operation with no intermediate rounding, thereby resulting in greater precision than if separate multiplication and addition had been performed. hardware is also provided to convert between integer and floating-point, to compare floating-point values, and to provide initial approximations for reciprocal and reciprocal square root. 4.1 compliance the floating point hardware conforms to the r equirements of the c standard, which is based on the ieee 754 floating point standard. the round-to-nearest, ties to even rounding mode is used for all instructions except float-to-inte- ger conversions. float-to-integer c onversions use the round-to-zero mode. the hardware supports denormal numbers. signalling nan are not provided, all nan are non-signalling (quiet). nans are not propagated, the default quiet nan is always returned (0x7fc00000). no floating-point exceptions are generated. 4.2 operations the floating-point instructions are mapped into t he coprocessor instruction space, but use the ordinary integer register file. the ordinary integer instructions such as memory accesses and logical operations can therefore be used on the same register data as the floating point hard- ware uses. therefore, no special floating-point data transfer instructions are required. all floating point instructions are mapped to coprocessor 0 cop instructions, i.e. they are aliases for cop instructions. attempting to execute instructions on any other coprocessor than coprocessor 0 will return a coprocessor absent exception. attempting to execute coprocessor 0 instructions other than cop on a device with floating point hardware will result in an unimplemented instruction exception. attempting to execute coprocessor 0 cop instructions on a device without floating point hard- ware will result in an unimpl emented instruction exception. 4.2.1 floating point compare (fcp.s) the floating point compare instruction, fcp.s , updates the status register flags. ordinary avr32 branch instructions such as breq and conditional instructions such as retge and movls can use axy ) ()
41 32002f?03/2010 avr32 the condition flags set by fcmp.s directly. the following mapping from floating point compare results to avr32 status register flags is used: 4.2.2 floating point check (fchk.s) this instruction checks the operand for special values, such as not-a-number (nan), infinity (inf) and denormal. status register flags are set according to the result of the fchk.s instruction. this instruction is useful since some algorithms requi re special treatment of these special values. the floating point approximation instructions updates the status register flags in the same way as fchk.s , since iterative approximation algorithms require special handling of these special values. ordinary avr32 branch instructions such as breq and conditional instructions such as retge and movls can use the condition flags set by fchk.s directly. table 4-1. floating point compare flag setting compare result status register flags less sreg[c] = 1 sreg[n] = 1 sreg[v] = 0 sreg[z] = 0 greater sreg[c] = 0 sreg[n] = 0 sreg[v] = 0 sreg[z] = 0 equal sreg[c] = 0 sreg[n] = 0 sreg[v] = 0 sreg[z] = 1 unordered sreg[c] = 0 sreg[n] = 0 sreg[v] = 1 sreg[z] = 0 table 4-2. floating point branch conditions branch if: avr32 branch condition mnemonic equal eq not equal ne greater than or equal ge greater than gt less than lo less than or equal ls unordered vs
42 32002f?03/2010 avr32 4.3 instruction set the following instructions are provided: : table 4-3. floating point arithm etical instructions mnemonics operands description issue latency fmac.s rd, ra, rx, ry multiply accumulate. (rd ra + rx*ry) 2 fnmac.s rd, ra, rx, ry multiply accumulate. (rd ? ra + rx*ry) 2 fmsc.s rd, ra, rx, ry multiply subtract. (rd ra ? rx*ry) 2 fnmsc.s rd, ra, rx, ry multiply subtract. (rd ? ra ? rx*ry) 2 fmul.s rd, rx, ry multiply. (rd rx*ry) 2 fnmul.s rd, rx, ry multiply. (rd ? rx*ry) 2 fadd.s rd, rx, ry add. (rd rx + ry) 2 fsub.s rd, rx, ry subtract. (rd rx ? ry) 2 table 4-4. floating point conversion instructions mnemonics operands description issue latency fcastrs.sw rd, ry convert float to signed word, round-to-zero. (rd (signed int)ry) 1 fcastrs.uw rd, ry convert float to unsigned word, round-to-zero. (rd (unsigned int)ry) 1 fcastsw.s rd, ry convert signed word to float, round-to-nearest. (rd (float)ry) 1 fcastuw.s rd, ry convert unsigned word to float, round-to- nearest. (rd (float)ry) 1
43 32002f?03/2010 avr32 : : 4.4 detailed inst ruction description table 4-5. floating point compare instructions mnemonics operands description issue latency fcp.s rd, rx compare floating point values in rd and rx, and set status register flags accordingly. 1 fchk.s ry check floating point value in rd for special values such as inf, nan and denormal, and set status register flags accordingly. 1 table 4-6. floating point approximation instructions mnemonics operands description issue latency frcpa.s rd, ry (rd approx(1/rx)), set status flags as fchk.s 1 frsqrta.s rd, ry (rd approx(1/sqrt(rx))), set status flags as fchk.s 1
44 32002f?03/2010 avr32 fmac.s ? floating point multiply-accumulate description performs multiply-accumulate of the registers spec ified and stores the result in destination regis- ter. operation: i. rd ra + rx*ry; syntax: i. fmac.s rd, ra, rx, ry operands: i. {a, d, x, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: 11100 0 11010 ra 31 29 28 25 24 20 19 16 0 0 0rd rx ry 15 0 0 0
45 32002f?03/2010 avr32 fnmac.s ? floating point ne gate-multiply-accumulate description performs negate-multiply-accumulate of the registers specified and stores the result in destina- tion register. operation: i. rd - ra + rx*ry; syntax: i. fnmac.s rd, ra, rx, ry operands: i. {a, d, x, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: 11100 0 11010 ra 31 29 28 25 24 20 19 16 0 0 1rd rx ry 15 0 0 0
46 32002f?03/2010 avr32 fmsc.s ? floating point multiply-subtract description performs multiply-subtract of the registers specified and stores the result in destination register. operation: i. rd ra - rx*ry; syntax: i. fmsc.s rd, ra, rx, ry operands: i. {a, d, x, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: 11100 0 11010 ra 31 29 28 25 24 20 19 16 0 0 0rd rx ry 15 0 1 0
47 32002f?03/2010 avr32 fnmsc.s ? floating point negate-multiply-subtract description performs negate-multiply-subtract of the register s specified and stores the result in destination register. operation: i. rd - ra - rx*ry; syntax: i. fnmsc.s rd, ra, rx, ry operands: i. {a, d, x, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: 11100 0 11010 ra 31 29 28 25 24 20 19 16 0 0 1rd rx ry 15 0 1 0
48 32002f?03/2010 avr32 fadd.s ? floating point add description performs addition of the registers specified and stores the result in destination register. operation: i. rd rx + ry; syntax: i. fadd.s rd, rx, ry operands: i. {d, x, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: 11100 1 1101000 0 31 29 28 25 24 20 19 16 0 0 0rd rx ry 15 0 0 0 0
49 32002f?03/2010 avr32 fsub.s ? floating point subtract description performs subtraction of the registers specified and stores the result in destination register. operation: i. rd rx - ry; syntax: i. fsub.s rd, rx, ry operands: i. {d, x, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: 11100 1 1101000 1 31 29 28 25 24 20 19 16 0 0 0rd rx ry 15 0 0 0 0
50 32002f?03/2010 avr32 fmul.s ? floating po int multiplication description performs multiplication of the registers specified and stores the result in destination register. operation: i. rd rx * ry; syntax: i. fmul.s rd, rx, ry operands: i. {d, x, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: 11100 1 1101000 0 31 29 28 25 24 20 19 16 0 0 0rd rx ry 15 0 0 0 1
51 32002f?03/2010 avr32 fnmul.s ? floating po int multiply-negate description performs multiply-negate of the registers specified and stores the result in destination register. operation: i. rd - rx * ry; syntax: i. fnmul.s rd, rx, ry operands: i. {d, x, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: 11100 1 1101000 1 31 29 28 25 24 20 19 16 0 0 0rd rx ry 15 0 0 0 1
52 32002f?03/2010 avr32 fcast{s,u}w.s ? convert from integer to floating point description converts the signed or unsigned integer specified and stores the result in destination register. the conversion used is rounds to nearest, ties to even. operation: i. rd (float)rx; rx is signed integer, round-to-nearest-even ii. rd (float)rx; rx is unsigned integer, round-to-nearest-even syntax: i. fcastsw.s rd, ry ii. fcastuw.s rd, ry operands: i-iv. {d, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: s=0: ry is an unsigned number, s=1: ry is signed number 11100 1 1101001 0 31 29 28 25 24 20 19 16 0 0 0rd 000ry 15 0 0 0 s 0
53 32002f?03/2010 avr32 fcastrs.{s,u}w ? convert from floating point to integer description converts the floating-point number in the specified register to a signed or unsigned integer and stores the result in destination register. rounding used is towards zero. operation: i. rd (signed int)rx; round towards zero ii. rd (unsigned int)rx; round towards zero syntax: i. fcastrs.sw rd, ry ii. fcastrs.uw rd, ry operands: i-iv. {d, y} {0, 1, ?, 15} status flags: q: not affected v: not affected n: not affected z: not affected c: not affected opcode: s=0: ry is an unsigned number, s=1: ry is signed number 11100 1 1101010 1 31 29 28 25 24 20 19 16 0 0 0rd 000ry 15 0 0 0 s 0
54 32002f?03/2010 avr32 fcp.s ? floating point compare description performs a compare between the two floating point operands specified. the operation is imple- mented by doing a floating-point subtraction without writeback of the difference. the operation sets the status flags according to the result of the subtraction, but does not affect the operand registers. see table 4-2, ?floating point branch conditions,? on page 41 for branch condition mnemonics corresponding to different compare results. operation: i. rx - ry; syntax: i. fcmp.s rx, ry operands: i. {x, y} {0, 1, ?, 15} status flags: q: not affected opcode: compare result status register flags less c 1 n 1 v 0 z 0 greater c 0 n 0 v 0 z 0 equal c 0 n 0 v 0 z 1 unordered c 0 n 0 v 1 z 0 11100 1 1101011 0 31 29 28 25 24 20 19 16 0 0 000 00 rx ry 15 0 0 0 0
55 32002f?03/2010 avr32 fchk.s ? floating point check for special values description checks the floating point operand specified for the special values infinity, not-a-number and denormal. a check is also performed for values with the two biggest possible representable exponents, i.e. 0xfd and 0xfe. this is useful fo r avoiding overflow in intermediate calculations in certain iterative algorithms. the operation sets the status flags according to the result of the check, but does not affect the operand register. operation: i. set flags depending on the value in the specified register syntax: i. fchk.s ry operands: i. y {0, 1, ?, 15} status flags: q: not affected predicate status register flag values if predicate true condition for branch if predicate true condition for branch if predicate false operand == nan c 1 n 1 v 0 z 0 lo gt operand == infinity c 0 n 0 v 0 z 0 gt lo operand == (denormal or (exponent==0xfd) or (exponent==0xfe)) c 0 n 0 v 0 z 1 eq ne operand == normal c 0 n 0 v 1 z 0 vs vc
56 32002f?03/2010 avr32 opcode: 11100 1 1101011 1 31 29 28 25 24 20 19 16 0 0 0rd 000 ry 15 0 0 0 0 0
57 32002f?03/2010 avr32 frcpa.s ? floating point reciprocal approximation description returns an approximation of the reciprocal of the operand. this can be used as a starting point for iterative approximation algorithms. also checks the operand for the special values infinity, not-a-number and denormal. a check is also performed for values with the two biggest possible representable exponents, i.e. 0xfd and 0xfe. this is useful for avoiding overflow in intermedi- ate calculations in certain iterative algorithms. the operation sets the status flags according to the result of this check. operation: i. rd approximatereciprocal(ry); set flags depending on the value in ry syntax: i. frcpa.s rd, ry operands: i. {d, y} {0, 1, ?, 15} status flags: q: not affected opcode: predicate status register flag values if predicate true condition for branch if predicate true condition for branch if predicate false operand == nan c 1 n 1 v 0 z 0 lo gt operand == infinity c 0 n 0 v 0 z 0 gt lo operand == (denormal or (exponent==0xfd) or (exponent==0xfe)) c 0 n 0 v 0 z 1 eq ne 11100 1 1101011 0 31 29 28 25 24 20 19 16 0 0 0rd 000 ry 15 0 0 0 1 0
58 32002f?03/2010 avr32 frsqrta.s ? floating point recipr ocal square root approximation description returns an approximation of the reciprocal of the square root of the operand. this can be used as a starting point for iterative approximation algorithms. also checks the operand for the special values infinity, not-a-number and denormal. a check is also performed for values with the two biggest possible representable exponents, i.e. 0xfd and 0xfe. this is useful for avoiding over- flow in intermediate ca lculations in certain iterative algorithms. the operation sets the status flags according to the result of this check. operation: i. rd approximatesquarerootreciprocal(ry); set flags depending on the value in ry syntax: i. frsqrta.s rd, ry operands: i. {d, y} {0, 1, ?, 15} status flags: q: not affected opcode: predicate status register flag values if predicate true condition for branch if predicate true condition for branch if predicate false operand == nan c 1 n 1 v 0 z 0 lo gt operand == infinity c 0 n 0 v 0 z 0 gt lo operand == (denormal or (exponent==0xfd) or (exponent==0xfe)) c 0 n 0 v 0 z 1 eq ne 11100 1 1101011 1 31 29 28 25 24 20 19 16 0 0 0rd 000 ry 15 0 0 0 1 0
59 32002f?03/2010 avr32 5. secure state revision 3 of the avr32 architecture introduc ed a separate system state allowing execution of secure or secret code alongs ide nonsecure code on the same processor. the secret code will execute in the secure state, and therefore be protected from hacking or readout by the code executing in the nonsecure state. customers not needing the secure state functio nality can just leave the associated hardware disabled, as it is by default, and the device will behave as pr evious versions of the avr32uc. 5.1 basic concept the secure state architecture extension divides the memory space into two sections, a secure section and a nonsecure section. the processor can be in one of two execution states, secure or nonsecure. the ss bit in the status register indicates which mode the processor is in. if the processor is in the secure state, it can access both secure and nonsecure memory spaces, but if it is in the nonsecure state, only nonsecure memory sections can be accessed. the ss_adrr and ss_adrf registers are used to configure the sizes of these secure sections. how the ss_adr registers map secure sections of the associated memories is determined by the indi- vidual memories, but usually ss_a dr is programmed with a secure memory size starting from the first address in the associated memory, ie. if ss_adrf is programmed with the value 0x800, the secure section of the flash contains the addresses from 0x8000_0000 to 0x8000_07ff. any sections of the ram and flash that are not in a secure section are considered nonsecure. the processor can pass between the secure and nonsecure state by using dedicated sscall and retss instructions. if an access to secure memory is attempted from nonsecure space, a bus error exception is asserted and the access is aborted. 5.2 typical use scenario the secure state hardware support allows our customers to program their proprietary ip code such as telecom stacks, dsp libraries etc into the secure section of th e memories. this secret code must be placed in a special secure section of the flash program memory, and locate its secret data structures in a special secure section of the ram. thereafter a dedicated fuse in non-volatile memory, ca lled the secure state enable (sse) fuse, is programmed. when set, this fuse blocks all external access to the secure memories, both from debuggers and programs run- ning in the nonsecure sections of the processor. the sse fuse can only be erased by a full chip erase, which will also erase all dat a in the memory secure sections. this partially programmed device can then be sold to customers who will program their software application into the nonsecure section of the memories. this software can communicate with the secret ip code through a secure api provided by the secret code. this allows the application to call routines in the secret software ip, however this ip is protected from hacking or unauthorized copying. after the application has been programmed into the partially programmed device, the security fuse in the flash is set, protecting the entire application from unauthorized readout by any end user.
60 32002f?03/2010 avr32 figure 5-1. typical secure state use scenario 5.3 secure stat e boot sequence at system boot time, hardware state machines preloads the secure state address registers with an initial value programme d into a secure section in the flash. also, the ss bit in the status reg- ister is preloaded with the value of the secure state enable (sse) fuse from the flash. this preloading is done before the system has completed the boot sequence, so the secure state address registers and sr[ss] are initialized befo re code starts executing and before the debug system has been enabled. 5.4 secure state debugging normally, debugging when executing in secure state should be turned off to prevent compromis- ing the secure code. however, it is useful to allow debugging of the secure state code during development of this code. a fuse in flash, called secure state debug enable (ssde), can be programmed to enable debugging of secure state code. 5.5 events in secure state normal risc state interrupt and exception handling has been described in section 3.7 ?event handling? on page 22 . this behavior is modified in the following way when interrupts and excep- tions are received in secure state: a sscall instruction will set sr[gm]. in secure st ate, sr[gm] masks bo th int0-int3, and nmi. clearing sr[gm], int0-int3 and nmi will re move the mask of th ese event sources. int0-int3 are still additionally masked by the i0m-i3 m bits in the status register. sscall has handler address at 0x8000_0004. exceptions have a handler address at 0x8000_0008. nmi has a handler address at 0x8000_000c. breakpoint has a handler address at 0x8000_0010. int0-int3 are not autovectored, but have a common handler address at 0x8000_0014. note that in the secure state, all exception sources share the same handler address. it is there- fore not possible to separate different exception causes when in the secure world. the secure world system must be designed to support this, the most obvious solution is to design the secure software so that exceptions will not ar ise when executing in the secure world. atmel empty device secure memories programmed sse set company a (secret ip) all memories programmed sse + flash security fuse set end user company b (application)
61 32002f?03/2010 avr32 6. memory system avr32uc implements a 32-bit unsegmented memory space. regions of this memory space can be protected by an optional mpu. the memory map is as follows: figure 6-1. the avr32uc memory map. 6.1 memory sections the memory map contains four sections, nam ed iram, local, boot and hsb. the iram section contains the internal ex stage memory, and this memory is mapped from address 0 and upwards. the local section is mapped from address 0x4000_0000 and is designed for con- taining device-specific high-speed interfaces, such as floating-point units, encryption hardware or high-speed gpio ports. access to the local space is performed using any ordinary load and store instructions, and is performed in a single clock cycle. mapping timing-critical devices in the local section is beneficial as the interface operates with high clock frequency, and its tim- ing is deterministic since it does not need to access a shared bus which may be heavily loaded. the boot section starts at address 0x8000_0000, which is the reset address for avr32uc. this section will typi cally contain an internal progr am flash, mapped from address 0x8000_0000 and upwards. the hsb section contains the addresses of all modules mapped on the hsb bus. this may include peripherals such as usarts and external memory interfaces. the memory space is uniform, so program c ode can execute from the iram, boot and hsb sections, and data accesses can be performed to any of the these sections. note that implemen- tations of avr32uc of may forbid certain accesses to certain memory sections, eg a write to program flash mapped into the boot section may be forbidden. the local section is only accessible by the load-store unit in the cpu ex pipeline stage, therefore, code can not be exe- cuted from addresses in the local space. 1 gb internal data ram 1gb high speed bus space 1gb boot program memory h'00000000 h'80000000 h'c0000000 h'ffffffff iram boot hsb 1gb cpu local bus memory local h'40000000
62 32002f?03/2010 avr32 6.2 memory interfaces the avr32uc cpu has three memory interfaces: if stage hsb master interface for instruction fetches ex stage hsb master interface for data accesses into boot or hsb sections ex stage hsb slave interface enabling other parts of the system to access addresses in the iram section 6.3 if stage interface the single master interface in the if stage performs instruction fetches. all fetches are per- formed with word alignment, except for the first fetch after a change-of-flow, which may use halfword alignment. the if stage can not perform writes, only reads are possible. reads can be perfomed from all addresses mapped on the hsb bus. reads are performed as incrementing bursts of unspecified length. t he if stage master interface will st all appropriately to support slow slaves. 6.4 ex stage interfaces the ex stage separates between cpu accesses to the iram section, and accesses to boot/hsb. any access to the iram section are performed to dedicated, high-speed rams implemented inside the memory controller. these fast rams are able to read or write within the cycle they are initiated. this means that a load instruction in ex will have the read-data ready at the end of the clock cycle for writing into the register file. 6.4.1 ex stage hsb master interface any cpu access to the boot or hsb sections will use multiple clock cycles, as dictated by the hsb semantics. writes to the boot or hsb sections can be pipelined, and are performed as a stream of nonsequential transfers, each taking one cycle unless stalled by the slave. if the slave stalls the transfer, the cpu will st all until the slave releases the stall. cpu reads from the boot or hsb sections are not pipelined, and transfer of a data therefore takes two clock cycles, one cycle for the address phas e, and one cycle for the data phase. the cpu will be stalled in the data phase. 6.4.2 ex stage hsb slave interface the avr32uc cpu provides a slave interface in to the high-speed rams that are implemented inside the memory controller. this interface enables other parts of the system, like dma control- lers, to write or read data to or from the rams. the slave interface support bursts for both reads and writes. if the high-speed rams for some reas on cannot accept the transfer request, it will reply by stalling th e request until it can be serviced. the arbitration priorities between the cpu and the slave interface for the rams can be con- trolled by programming the cpu control register (cpucr). the cpucr is described in section 2.5 on page 11 . arbitration is performed according to the following rules: assuming the memory interface is idle, and no memory transfers have been performed. who- ever requests access to the rams will win the ar bitration and get access. if both the cpu and the slave interfac e requests access, the cpu will win. the source that won the arbitration can use the rams for as long as they require. if the other source also has a pending request for use of t he ram, this source will have to wait maximum the number of cycles specified by the spl or cpl fields of cp ucr. the pending source will gain
63 32002f?03/2010 avr32 access to the rams when the current owner voluntarily releases the rams, or after the spl/cpl timeout period, whichever comes first. if the cpu wins arbitration for the rams, the cpu is guaranteed to own the ram for the period specified by the cop field in cpucr. any slav e request will be left pending during this period, even if the cpu is not using the rams. the following state diagram shows the states in arbitration for the ram. figure 6-2. arbitration between cpu and slave interface for rams. the state transitions are as follows: 1: cpu_wants_to_perform_mem_access 2: cpu_access_complete && (been_in_state > cpucr[cop]) 3: (been_in_state > cpucr[cop]) && slave_wants_to_perform_mem_access && (slave_been_pending > cpucr[spl]) 4: cpu_wants_to_perform_mem_access && (cpu_been_pending > cpucr[cpl]) 5: slave_wants_to_perform_mem_access && !cpu_wants_to_perform_mem_access 6: slave_access_complete 6.4.3 ex stage local bus interface any cpu access to the the local section is comp leted in a single clock cycle, both for reads and writes. transfers on this bu s can not be stalled. the cpu will never be stalled due to an access to the local section. accesses to th is section is performed using regular load-store instructions such as for example ldswp.w , ld.w , ld.ub , st.w , stswp.w , ldm or stm . which devices are mapped in the local section, and their memory maps, is device-specific. the local interface must be enabled by the user by programming the locen bit in cpucr. accesses to local memory ad dresses without first enabling t he section will result in a bus error exception. if the mpu is enabled, accesses to loca l will be subject to permission checking. to ensure maximum transfer speed and cycle dete rminism, any slaves being addressed by the cpu on the local bus must be able to receive and transmit data on the bus at cpu clock speeds. the consequences of this may vary between diffe rent slave devices, but for some slave devices it may imply that the slaves have to run at the cpu clock frequency when local bus transfers are ram is free cpu owns the ram slave i/f owns the ram 1 2 3 4 5 6
64 32002f?03/2010 avr32 being performed. refer to the device datasheet for information on any relationships between cpu and device clock frequencies imposed by the local bus. 6.5 iram write buffer the ex stage has a write buffer used to hold data to be written to the iram section. the opera- tion of this buffer is usually transparent to the programmer. the programmer should be aware of the following: the iram has a single port, allowing either one read or one write per clock cycle. the write buffer is pipelined, allowing sequenti al writes to iram to be pipelined without any pipeline stalls. the previous contents of the writ e buffer is written to the ram in parallel with the new store data being placed in the write buffer. any read instruction to iram in ex will be perf ormed immediately, even if a previous store instruction has placed data to store in the write buffer. in this case, the previous store data remains in the write buffer and will be wr itten back to ram in a later clock cycle. if a read instruction in ex accesses the same address as the data in the write buffer is to be stored to, the pipeline is stalled for one clock cycle while the write buffer is emptied to ram. the read will be performed normally in the next clock cycle. the contents of the write buffer is writte n to the physical ram as soon as the memory interface is not used by any instructions. the state of the write buffer may affect the timing of rmw instructions, see ?read-modify- write instructions? on page 84 for details 6.6 memory barriers memory barriers are constructs used to enfore memory consitency. caches and self-modifying code may cause memory to become inconsist ent. avr32uc has a simple pipeline with no caches, so there is usually no need for memory barriers. mechanisms for memory barriers are present to handle the cases where such barriers are needed. 6.6.1 instruction memory barriers an instruction memory barrier (imb) is usually only needed when executing self-modifying code, for example when self-programming program flash. in this case, one must ensure that all levels in the memory hierarchy are consistent. due to the simple non-cached memory system in avr32uc, this is usually trivial. the programmer should make sure that an imb is used if ther e is a possibility that an instruction to be modified by self-modifying code has alr eady been prefetched by the instruction prefetch unit. in this case, an imb should be inserted between the instruction modifying the code and the execution of the modified instruction. to make sure that the modified version of the instruction is executed, the prefetch buffer should be flushed between changing the program memory and executing the new version of the program. any instruction performing a change-of flow, such as return from exception, conditional branches, unconditional branches, subprogram call or return, or instructions writing to pc would implement an imb in avr32uc. 6.6.2 data memory barriers a data memory barrier (dmb) is used to make su re that a data memory access, either a read or write, is actually performed before the rest of the code is executed. caches, write buffers and
65 32002f?03/2010 avr32 bus latency may cause a memory access to be seen by a slave many cycles after it has been executed by the pipeline. in some cases, th is may lead to unpredictable behavior in the system. one example of this is found in interrupt handlers. one usually wants to make sure that the inter- rupt request has been cleared before executing the rete instruction, otherwis e the same interrupt may be serviced immediately after executing the rete instruction. in this case a dmb must be inserted between the code clearing the interrupt request and the rete . all accesses to hsb space are strongly ordered. this is used to impl ement dmbs. a dmb after a store to a hsb slave is implemented by perfo rming a dummy read from the same slave. any critical code after the read will stall until the read ha s been performed. consider an interrupt request made by a peripheral. this peripheral will disassert the interrupt request as soon as the interrupt handler has written a specific bitmask to its periph_intclear register. a read from the same peripheral performs a bus transfer that implements the dmb. the rete instruction can be executed after the dmb. code 6-1. clearing irqs using da ta memory barriers // using data memory barriers in the irq handler to make sure that the // request has been disasserted before returning from the handler // assume that the irq is cleared by writing a bitmask to periph_intclear. // r0 points to this register, r1 contains the correct bitmask. irq_handler: st.w r0[0], r1 ld.w r12, r0[0] // data memory barrier rete
66 32002f?03/2010 avr32 7. memory protection unit the avr32 architecture defines an optional memory protection unit (mpu). this is a simpler alternative to a full mmu, while at the same time allowing memory protection. the mpu allows the user to divide the memory space into different protection regions. these protection regions have a user-defined size, and starts at a user-defined address. the different regions can have different cacheability attributes an d bufferability attribut es. each region is di vided into 16 subre- gions, each of these subregions can have on e of two possible sets of access permissions. the mpu does not perform any address translation. 7.1 memory map in systems with mpu an avr32 implemetation with a mpu has a fl at, unsegmented memory space. access permis- sions are given only by the different protection regions. 7.2 understanding the mpu the avr32 memory protection unit (mpu) is responsible for checking that memory transfers have the correct permissions to complete. if a memory access with unsati sfactory privileges is attempted, an exception is generated and the access is aborted. if an access to a memory address that does not reside in any protection region is attempted, an exception is generated and the access is aborted. the user is able to allow different privilege levels to different blocks of memory by configuring a set of registers. each such block is called a protection region. each region has a user-program- mable start address and size. the mpu allows the user to program 8 different protection regions. each of these regions have 16 sub-r egions, which can have different access permis- sions, cacheabilit y and bufferability. the ?dmmu sz? fields in the config1 system register identifies the number of implemented protection regions, and therefore also the number of mpu registers. an avr32uc system with caches also have mp u cacheability and bu fferability registers. a protection region can be from 4 kb to 4 gb in size, and the size must be a power of two. all regions must have a start address that is aligned to an address corresponding to the size of the region. if the region has a size of 8 kb, the 13 lowe st bits in the start address must be 0. failing to do so will result in undefined behaviour. sinc e each region is divi ded into 16 sub-regions, each sub-region is 256 b to 256 mb in size. when an access hits into a memory region set up by the mpu, hardware proceeds to determine which subregion the access hits into. this info rmation is used to determine whether the access permissions for the subregi on are given in mpuapra/mpubra/mpucra or in mpuaprb/mpubrb/mpucrb. if an access does not hit in any region, the tr ansfer is aborted and an exception is generated. the mpu is enabled by writing setting the e bit in the mpucr register. the e bit is cleared after reset. if the mpu is disabled, all accesses ar e treated as uncacheable, unbufferable and will not generate any access violations. before setting the e bit, at least one valid protection region must be defined. 7.2.1 mpu interface registers the following registers are used to control the mpu, and provide the interface between the mpu and the operating system, see figure 7-1 on page 67 . all the registers are mapped into the sys-
67 32002f?03/2010 avr32 tem register space, their addresses are presented in ?system registers? on page 11 . they are accessed with the mtsr and mfsr instructions. the mpu interface registers are shown below. th e suffix n can have the range 0-7, indicating which region the register is associated with. figure 7-1. the mpu interface registers 7.2.1.1 mpu address register - mpuarn a mpu address register is implemented for each of the 8 protection regions. the mpuar regis- ters specify the start address and size of the regions. the start address must be aligned so that its alignment corresponds to the size of the regi on. the minimum allowable size of a region is 4 kb, so only bits 31:12 in the base address needs to be specified. the other bits are always 0. each mpuar also has a valid bit t hat specifies if the protection re gion is valid. only valid regions are considered in the protection testing. the mpuar register consists of the following fields: base address - the start address of the region. the minimum size of a region is 4kb, so only the 20 most significant bits in the base address needs to be specified. the 12 lowermost base address bits are implicitly set to 0. if protection regions larger than 4 kb is used, the user must write the appropriate bits in base address to 0, so that the base address is aligned to the size of the region. otherwise, the result is undefined. base address size 0 5 12 31 mpuarn - 0 31 - 876 4321 0 31 0 31 e 0 31 mpucr - 1 11 6 v 1 mpucra / mpucrb 5 mpubra / mpubrb - 876 4321 5 mpuapra / mpuaprb ap0 ap1 ap2 ap3 ap4 ap5 ap6 ap7 3 4 7 8 11 12 15 16 19 20 23 24 27 28 - 31 mpupsrn p10 p11 p12 p13 p14 p15 p4 p5 p6 p7 p8 p9 p0 p1 p2 p3 0 876 4321 5 9 16 15 13 12 11 10 14 c4 c5 c6 c7 c0 c1 c2 c3 b4 b5 b6 b7 b0 b1 b2 b3
68 32002f?03/2010 avr32 size - size of the protection region. the possible sizes are shown in table 7-1 on page 68 . v - valid. set if the protection region is valid, cleared otherwise. this bit is written to 0 by a reset. the region is not considered in the protection testing if the v bit is cleared. 7.2.1.2 mpu permission select register - mpupsrn a mpu permission select register is implemented for each of the 8 protection regions. each mpupsr register divides the protection regi on into 16 subregions. the bitfields in mpupsr specifies whether each subregion has access permissions as specified by the region entry in either mpuapra or mpuaprb. table 7-1. protection region sizes implied by the size field size region size constr aints on base address b?00000 to b?01010 undefined - b?01011 4 kb none b?01100 8 kb bit [12] in base address must be 0 b?01101 16 kb bit [13:12] in base address must be 0 b?01110 32 kb bit [14:12] in base address must be 0 b?01111 64 kb bit [15:12] in base address must be 0 b?10000 128 kb bit [16:12] in base address must be 0 b?10001 256 kb bit [17:12] in base address must be 0 b?10010 512 kb bit [18:12] in base address must be 0 b?10011 1 mb bit [19:12] in base address must be 0 b?10100 2 mb bit [20:12] in base address must be 0 b?10101 4 mb bit [21:12] in base address must be 0 b?10110 8 mb bit [22:12] in base address must be 0 b?10111 16 mb bit [23:12] in base address must be 0 b?11000 32 mb bit [24:12] in base address must be 0 b?11001 64 mb bit [25:12] in base address must be 0 b?11010 128 mb bit [26:12] in base address must be 0 b?11011 256 mb bit [27:12] in base address must be 0 b?11100 512 mb bit [28:12] in base address must be 0 b?11101 1 gb bit [29:12] in base address must be 0 b?11110 2 gb bit [30:12] in base address must be 0 b?11111 4 gb bit [31:12] in base address must be 0 table 7-2. subregion access permission implied by mpupsr bitfields mpupsrn[p] access permission 0 mpuapra[apn] 1 mpuaprb[apn]
69 32002f?03/2010 avr32 7.2.1.3 mpu cacheable regi ster a / b- mpucra / mpucrb the mpucr registers have one bit per region, indicating if the region is cacheable. if the corre- sponding bit is set, the region is cacheable. the register is written to 0 upon reset. avr32uc implementations may optionally choose not to implement the mpucr registers. 7.2.1.4 mpu bufferable register a / b- mpubra / mpubrb the mpubr registers have one bit per region, indicating if the region is bufferable. if the corre- sponding bit is set, the region is bufferable. the register is written to 0 upon reset. avr32uc implementations may optionally choose not to implement the mpubr registers. 7.2.1.5 mpu access permission register a / b - mpuapra / mpuaprb the mpuapr registers indicate the access per missions for each region. the mpuapr is writ- ten to 0 upon reset. the possible access permissions are shown in table 7-3 on page 69 . 7.2.1.6 mpu control register - mpucr the mpucr controls the operation of the mpu. the mpucr has only one field: e - enable. if set, the mpu address checking is enabled. if cleared, the mpu address checking is disabled and no except ions will be generated by the mpu. 7.2.2 mpu exception handling this chapter describes the exceptions that can be signalled by the mpu. 7.2.2.1 itlb protection violation an itlb protection violation is issued if an instruction fetch violates access permissions. the vio- lating instruction is not executed. the address of the failing instruction is placed on the system stack. table 7-3. access permissions implied by the apn bits ap privileged mode unprivileged mode b?0000 read none b?0001 read / execute none b?0010 read / write none b?0011 read / write / execute none b?0100 read read b?0101 read / execute read / execute b?0110 read / write read / write b?0111 read / write / execute read / write / execute b?1000 read / write read b?1001 read / write read / execute b?1010 none none other undefined undefined
70 32002f?03/2010 avr32 7.2.2.2 dtlb protection violation an dtlb protection violation is issued if a data access violates access permissions. the violat- ing access is not executed. the address of the failing instruction is placed on the system stack. 7.2.2.3 itlb miss violation an itlb miss violation is issued if an instructi on fetch does not hit in any region. the violating instruction is not executed. the address of the failing instruction is placed on the system stack. 7.2.2.4 dtlb miss violation an dtlb miss violation is issued if a data a ccess does not hit in any region. the violating access is not executed. the add ress of the failing instruction is placed on the system stack. 7.2.2.5 tlb multiple hit violation an access hit in multiple protection regions. the address of the failing instruction is placed on the system stack. this is a critical system error that should not occur. 7.3 example of mpu functionality as an example, consider region 0. let region 0 be of size 16 kb, thus each subregion is 1kb. subregion 0 has offset 0-1kb from the base address, subregion 1 has offset 1kb-2kb and so on. mpuapra and mpuaprb each has one field per region. each subregion in region 0 can get its access permissions from either mpuapra[ap0] or mpuaprb[ap0], th is is selected by the sub- region?s bitfield in mpupsr0. let: mpupsr0 = {0b0000_0000_0000_0000, 0b1010_0000_1111_0101} mpuapra = {a, b, c, d, e, f, g, h} mpuaprb = {a, b, c, d, e, f, g, h} where {a-h, a-h} have legal values as defined in table 7-3 . thus for region 0: table 7-4. example of access rights for subregions subregion access permission subregion access permission 0h8h 1h9h 2h10h 3h11h 4h12h 5h13h 6h14h 7h15h
71 32002f?03/2010 avr32 8. instruction cycle summary this chapter presents the instructions in avr32 uc cpu, and the number of clock cycle they require to complete. all the instructions in each group behave similarly in the pipeline. the final subchapter presents code examples to illustrate the clock cycle requirements of various code constructs. 8.1 definitions the following definitions are presented in the tables below: 8.1.1 issue an instruction is issued when it leaves the id stage and enters the ex stage. 8.1.2 issue latency the issue latency represents the number of clock cycles required between the issue of the instruction and the issue of the following instruction. for some change-of-flow instructions, this includes the cycle penalty caused by the pipeli ne flush. the issue latency assumes, unless stated otherwise, that the instruction and data memories are able to return an instruction or data in a single cycle, which may not be true for sl ow program memories or data memories mapped on the hsb bus. 8.2 special considerations 8.2.1 pc as destination register most instructions can take pc as destination register. this will resu lt in a jump to the calculated address. the jump is performed when the instruction writing to pc has completed, and all other effects of the instruction, like updating of pointer registers for load instructions with pc as target instruction, have been committed. instructions writing to pc will have an additional issue latency of 2 cycles due to the pipeline flush. 8.2.2 alignment of change-of-flow targets the cycle count number for change-of-flow instructi ons assumes that the target instruction is a compact instruction or word-alig ned extended instruction. an ex tra cycle will be required if the target instruction is a halfword-aligned extended instruction, since both halves of the instruction must be fetched before it can be issued. 8.2.3 memory and bus timings performance of memory accesses and instruction fetching are affected by the performance of system memories and system bus. the following are examples of factors that may affect the cycle count of such operations: accesses to the iram section in parallel with another bus master, for example a dma controller. accesses to memories with wait states, for example flash or external memories. using system buses with wait states or arbitration overhead. accesses to memories that are simultaneously being accessed by other bus masters.
72 32002f?03/2010 avr32 8.3 cpu revision revision 1, 2 and 3 of the avr32uc cpu has the same instruction timings, except that the divider in revision 2 and later is faster than in re vision 1. instructions only present in revision 2 or 3 of the cpu are explicitly noted. 8.4 alu instructions this group comprises simple si ngle-cycle alu instructions like add and sub. the conditional subtract and move instructions are also in this group. all instructions in this group, except ssrf to bits 15 to 31, take one cycle to execute, and the result is available for use by the following instruction. table 8-1. alu instructions mnemonics operands description issue latency abs c rd absolute value. 1 acr c rd add carry to register. 1 adc e rd, rx, ry add with carry. 1 add c rd, rs add. 1 e rd, rx, (ry << sa) add shifted. 1 add{cond4} e rd, rx, ry add if condition satisfied. cpu revision 2 and higher only. 1 addhh.w c rd, rx, ry add signed halfwords (32 16 + 16) 1 addabs e rd, rx, ry add with absolute value. 1 cp.b e rd, rs compare byte. 1 cp.h e rd, rs compare halfword. 1 cp.w crd, rs compare. 1 crd, imm 1 erd, imm 1 cpc crd compare with carry. 1 erd, rs 1 max e rd, rx, ry return signed maximum 1 min e rd, rx, ry return signed minimum 1 neg c rd two?s complement. 1 rsub crd, rs reverse subtract. 1 e rd, rs, k8 1 rsub{cond4} e rd, imm reverse subtract immediate if condition satisfied. cpu revision 2 and higher only. 1 sbc e rd, rx, ry subtract with carry. 1 scr c rd subtract carry from register. 1
73 32002f?03/2010 avr32 sub crd, rs subtract. 1 e rd, rx, (ry << sa) 1 crd, imm 1 erd, imm 1 e rd, rs, imm 1 subhh.w c rd, rx, ry subtract signed halfwords (32 16 - 16) 1 sub{cond4} e rd, imm subtract immediate if condition satisfied. 1 erd, imm subtract if condition satisfied. cpu revision 2 and higher only. 1 tnbz c rd test no byte equal to zero. 1 and crd, rs logical and. 1 e rd, rx, ry << sa 1 e rd, rx, ry >> sa 1 and{cond4} e rd, rx, ry logical and if condition satisfied. cpu revision 2 and higher only. 1 andn c rd, rs logical and not. 1 andh erd, imm logical and high halfword, low halfword is unchanged. 1 e rd, imm, coh logical and high halfword, clear other halfword. 1 andl erd, imm logical and low halfword, high halfword is unchanged. 1 e rd, imm, coh logical and low halfword, clear other halfword. 1 com c rd one?s complement (not). 1 eor crd, rs logical exclusive or. 1 e rd, rx, ry << sa 1 e rd, rx, ry >> sa 1 eor{cond4} e rd, rx, ry logical eor if condition satisfied. cpu revision 2 and higher only. 1 eorh e rd, imm logical exclusive or (high halfword). 1 eorl e rd, imm logical exclusive or (low halfword). 1 or crd, rs logical (inclusive) or. 1 e rd, rx, ry << sa 1 e rd, rx, ry >> sa 1 or{cond4} e rd, rx, ry logical or if condition satisfied. cpu revision 2 and higher only. 1 table 8-1. alu instructions
74 32002f?03/2010 avr32 orh e rd, imm logical or (high halfword). 1 orl e rd, imm logical or (low halfword). 1 tst c rd, rs test register for zero. 1 bfins e rd, rs, o5, w5 insert the lower w5 bits of rs in rd at bit-offset o5. 1 bfexts e rd, rs, o5, w5 extract and sign-extend the w5 bits in rs starting at bit-offset o5 to rd. 1 bfextu e rd, rs, o5, w5 extract and zero-extend the w5 bits in rs starting at bit-offset o5 to rd. 1 bld e rd, b5 bit load. 1 brev c rd bit reverse. 1 bst e rd, b5 bit store. 1 casts.b c rd typecast byte to signed word. 1 casts.h c rd typecast halfword to signed word. 1 castu.b c rd typecast byte to unsigned word. 1 castu.h c rd typecast halfword to unsigned word. 1 cbr c rd, b5 clear bit in register. 1 clz e rd, rs count leading zeros. 1 sbr c rd, b5 set bit in register. 1 swap.b c rd swap bytes in register. 1 swap.bh c rd swap bytes in each halfword. 1 swap.h c rd swap halfwords in register. 1 asr e rd, rx, ry arithmetic shift right (signed). 1 e rd, rs, sa 1 c rd, sa 1 lsl e rd, rx, ry logical shift left. 1 e rd, rs, sa 1 c rd, sa 1 lsr e rd, rx, ry logical shift right. 1 e rd, rs, sa 1 c rd, sa 1 rol c rd rotate left through carry. 1 ror c rd rotate right through carry. 1 mov crd, imm load immediate into register. 1 erd, imm 1 c rd, rs copy register. 1 mov{cond4} e rd, rs copy register if condition is true 1 e rd, imm load immediate into register if condition is true 1 table 8-1. alu instructions
75 32002f?03/2010 avr32 8.5 multiply instructions these instructions require one pass through the multiplier array and produce a 32- or 48-bit result. for mulrndhh , a rounding value of 0x8000 is added to the product producing the final result. this group does not set any flags, except for the mulsat instructions whic h set q if satura- tion occurred. movh e rd, imm load immediate into high halfword of register. cpu revision 2 and higher only. 1 csrf c b5 clear status register flag. 1 csrfcz c b5 copy status register flag to c and z. 1 ssrf c b5 set status register flag. 1 / 3 sr{cond4} c rd conditionally set register to true or false 1 table 8-1. alu instructions table 8-2. multiply instructions mnemonics operands description issue latency mul e rd, rx, ry multiply. (32 32 x 32) 1 e rd, rs, imm multiply immediate. 1 mulhh.w e rd, rx, ry signed multiply of halfwords. (32 16 x 16) 1 mulnhh.w e rd, rx, ry signed multiply of halfwords. (32 16 x 16) 1 mulnwh.d e rd, rx, ry signed multiply, word and halfword. (48 32 x 16) 1 mulwh.d e rd, rx, ry signed multiply, word and halfword. (48 32 x 16) 1 mulsathh.h e rd, rx, ry fractional signed multiply with saturation. return halfword. (16 16 x 16) 1 mulsathh.w e rd, rx, ry fractional signed multiply with saturation. return word. (32 16 x 16) 1 mulsatwh.w e rd, rx, ry fractional signed multiply with saturation. return word. (32 32 x 16) 1 mulsatrndhh.h e rd, rx, ry signed multiply with rounding. return halfword. (16 16 x 16) 1 mulsatrndwh. w e rd, rx, ry signed multiply with rounding. return halfword. (32 32 x 16) 1
76 32002f?03/2010 avr32 8.6 mac instructions these instructions require one pass through the multiplier array and produce a 32- or 48-bit result. this result is added to an accumulator regi ster. a valid copy of this accumulator may be cached in the accumulator cache. otherwise, an extra cycle is needed to read the accumulator from the register file. therefore, issue and result latencies depend on whether the accumulator is cached in the acccache. this group does not set any flags, except for the macsathh.w instruction which set q if saturation occurred. 8.7 mulmac64 instructions these instructions require two passes through the multiplier array to produce a 64-bit result. for macs.d and macu.d , a valid copy of this accumulator may be cached in the accumulator cache. otherwise, an extra cycle is needed to read the accumulator from the register file. therefore, issue and result latencies depend on whether a valid entry is found in the accumulator cache. table 8-3. mac instructions mnemonics operands description issue latency mac e rd, rx, ry multiply accumulate. (32 32x32 + 32) 1/2 machh.w e rd, rx, ry multiply signed halfwords and accumulate. (32 16x16 + 32) 1/2 machh.d e rd, rx, ry multiply signed halfwords and accumulate. (48 16x16 + 48) 1/2 macwh.d e rd, rx, ry multiply signed word and halfword and accumulate. (48 32 x 16 + 48) 1/2 macsathh.w e rd, rx, ry fractional signed multiply accumulate with saturation. return word. (32 16 x 16 + 32) 1/2 table 8-4. mulmac64 instructions mnemonics operands description issue latency macs.d e rd, rx, ry multiply signed accumulate. (64 32x32 + 64) 3/4 macu.d e rd, rx, ry multiply unsigned accumulate. (64 32x32 + 64) 3/4 muls.d e rd, rx, ry signed multiply. (64 32 x 32) 2 mulu.d e rd, rx, ry unsigned multiply. (64 32 x 32) 2
77 32002f?03/2010 avr32 8.8 divide instructions these instructions require several cycl es in the ex stage to complete. the divs and divu instruc- tions will be aborted immediately if any interrupts are pending, in order to limit the interrupt latency. the divide instructions are faster in revision 2 than in revision 1 of the avr32uc cpu. 1.) 35 cycles in revision 1 of the cpu 8.9 saturate instructions these instructions perform arithmetic operations with possible saturation. 8.10 load and store instructions this group includes all the load and store instru ctions. the address calculations are performed by the adder in the ex stage. the ex adder also performs the writeback address calculation for the autoincrement and autodecrement operation. loaded data are available at the end of the cycle in the ex stage. byte and halfword data must be extended and rotated before they are valid. this is performed in the ex stage. ldins and ldswp instructions also require modification in the ex stage before their results are valid. stswp instructions require modification before their data is output to the memory interface. this modifi- cation is performed in the ex stage. table 8-5. divide instructions mnemonics operands description issue latency divs e rd, rx, ry divide signed. (32 32/32) (32 32%32) 19 1 divu e rd, rx, ry divide unsigned. (32 32/32) (32 32%32) 19 1 table 8-6. saturate instructions mnemonics operands description issue latency satadd.h e rd, rx, ry saturated add halfwords. 1 satadd.w e rd, rx, ry saturated add. 1 satsub.h e rd, rx, ry satura ted subtract halfwords. 1 satsub.w e rd, rx, ry saturated subtract. 1 e rd, rs, imm 1 satrnds e rd >> sa, b5 signed saturate from bit given by sa after a right shift with rounding of b5 bit positions. 2 satrndu e rd >> sa, b5 unsigned saturate from bit given by sa after a right shift with rounding of b5 bit positions. 2 sats e rd >> sa, b5 shift sa positions and do signed saturate from bit given by b5. 1 satu e rd >> sa, b5 shift sa positions and do unsigned saturate from bit given by b5. 1
78 32002f?03/2010 avr32 the stcond instruction takes 2 cycles if the store is not performed, 3 cycles if the store is performed. all issue latencies are given for accesses to ir am or local. these timings must be modified as follows for accesses to boot or hsb sections: a byte, halfword or word load requires 1+ w cycles in addition to the count listed in table 8-7 , where w is the number of wait states from the slave and bu s system. the pipeline will stall during these cycles. a doubleword load performs two memory accesses, so 2(1+w) cycles are needed in addition to the count listed in table 8-7 . the pipeline will stall during these cycles. a byte, halfword or word store requires (1+w) cycles in addition to the count listed in table 8- 7 , where w is the number of wait states from the slave and bus system. stores to boot or hsb can be performed in the background, so the pipeline will only stall if another memory access is attempted during these w cycles. however, multiple stores to addresses in boot or hsb can be automatically combined by the me mory interface to create bursts on the hsb bus. this means that any consecutive stores to boot or hsb sections will not stall the pipeline unless the bus itself inserts wait cycles, for example due to wait states or bus contention. instructions not performing memory accesses will never stall the pipeline when executed after stores to boot or hsb. a doubleword store performs two memory acce sses, but these will be pipelined. the last of these accesses will stall if the instruction following the doubleword is a memory access instruction other than a store to boot or hsb. therefore, a non-memory instruction or another store to boot or hsb should be scheduled after a doubleword store to boot or hsb for maximum performance. table 8-7. load and store instructions mnemonics operands description issue latency iram ld.ub c rd, rp++ load unsigned byte with post-increment. 2 c rd, --rp load unsigned byte with pre-decrement. 2 c rd, rp[disp] load unsigned byte with displacement. 1 e rd, rp[disp] 1 e rd, rb[ri< 79 32002f?03/2010 avr32 ld.uh c rd, rp++ load unsigned halfwo rd with post-increment. 2 c rd, --rp load unsigned halfword with pre-decrement. 2 c rd, rp[disp] load unsigned halfword with displacement. 1 e rd, rp[disp] 1 e rd, rb[ri< << 2] load word with extracted index. 1 ld.w{cond4} e rd, rp[disp] load word with displacement if condition satisfied. cpu revision 2 and higher only. 1 ld.d c rd, rp++ load doubleword with post-increment. 3 c rd, --rp load doubleword with pre-decrement. 3 c rd, rp load doubleword. 2 e rd, rp[disp] load double with displacement. 2 e rd, rb[ri<, rp[disp] load byte with displacement and insert at specified byte lo cation in rd. 1 ldins.h e rd, rp[disp] load halfword with displacement and insert at specified halfword location in rd. 1 ldswp.sh e rd, rp[disp] load halfword with displacement, swap bytes and sign-extend. 1 ldswp.uh e load halfword with displacement, swap bytes and zero-extend. 1 ldswp.w e load word with displacement and swap bytes. 1 lddpc c rd, pc[disp] load with displacement from pc. 1 table 8-7. load and store instructions
80 32002f?03/2010 avr32 lddsp c rd, sp[disp] load with displacement from sp. 1 st.b c rp++, rs store with post-increment. 1 c --rp, rs store with pre-decrement. 1 c rp[disp], rs store byte with displacement. 1 e rp[disp], rs 1 e rb[ri< 81 32002f?03/2010 avr32 8.11 multiple data memo ry access instructions these instructions perform multiple data accesses. the incremental accesses are performed as word accesses. the number of cycles is dependent on the number of registers to load or store, n . the issue latency must be modified as follows: ldm and popm will use an additional c ycle if testing of r12 is performed ldm and popm that updates pc will cause a c hange-of-flow, which is performed in parallel with the pointer writeback and therefore has a penalty of only one cycle. the issue latency for hsb accesse s increases if the hsb bus is busy or the slave inserts wait states. the instructions in this group will be aborted immediately if any interrupts are pending, in order to limit the interrupt latency. table 8-8. multiple data memory accesses mnemonics operands description issue latency iram issue latency hsb ldm e rp, reglist16 load multiple registers. r12 is tested if pc is loaded. if pc is in the register list, p=1, otherwise p=0. 1+n+p 1+2n+p ldm e rp++, reglist16 load multiple registers. r12 is tested if pc is loaded. 2+n 1+2n ldmts e rp, reglist16 load multiple registers for task switch. 1+n 1+2n ldmts e rp++, reglist16 load multiple registers for task switch. 2+n 1+2n popm c reglist8 pop multiple registers from stack. r12 is tested if pc is popped. 2+n 1+2n pushm c reglist8 push multiple registers to stack. 2+n 3+n stm e rp, reglist16 store multiple registers. 1+n 2+n stm e --rp, reglist16 store multiple registers. 2+n 3+n stmts e rp, reglist16 store multiple registers for task switch. 1+n 2+n stmts e --rp, reglist16 store multiple registers for task switch. 2+n 3+n
82 32002f?03/2010 avr32 8.12 branch instructions the branch instructions cause a pipeline flush and change-of-flow if taken. two cycles must be added to the issue latency if the branch is taken. 8.13 call instructions call instructions behave similarly to branches, ex cept that the link register (lr) must be updated. the issue latency presented in the table includes the branch penalty. the breakpoint instruction takes a single cycle if debug mode is disabled, in this case it exe- cutes as a nop . the breakpoint instruction updates rar_dbg instead of lr. 8.14 return from execution mode instructions the rete and rets instruction may pop the status register and return address from the system stack, and perform a branch to the return address. the retd instruction gets the return address and return status registers from the rar_db g and rsr_dbg system registers. the issue latency presented in the table includes the branch penalty. table 8-9. branch instructions mnemonics operands description issue latency br{cond3} c disp branch if condi tion satisfied. 1 br{cond4} e disp 1 rjmp c disp relative jump. 1 ret{cond4} c rs conditional return from subroutine with move and test of return value. 1 table 8-10. call instructions mnemonics operands description issue latency acall c disp application call 4 icall c rd register indirect call. 4 mcall e rp[disp] memory call. 4 rcall cdisp relative call. 4 edisp 4 scall c supervisor call 6 sscall c secure state call. cpu revision 3 and higher only. 5 breakpoint c breakpoint. 3
83 32002f?03/2010 avr32 the rete instruction has a latency of 12 cycles when returning from int0-int3 modes, 5 cycles otherwise. the rete instruction can be aborted by a pending interrupt. 8.15 swap instructions the swap instruction performs two atomical memory accesses, first one read and then one write. 8.16 system register instructions this group moves data to and from the system registers. accesses to system registers are per- formed in the ex stage, taking one cycle. mtsr to sreg takes 3 cycles, mtsr to a ll other system regist ers takes 1 cycle. 8.17 system control instructions this group contains simple single-cycle instructi ons that control the behaviour of different parts of the system. the frs , pref and sync instructions are executed as nop in avr32uc. table 8-11. return from execution mode instructions mnemonics operands description issue latency retd c return from debug mode 3 rete c return from exception 5 / 12 rets c return from supervisor call 5 retss c return from secure state call. cpu revision 3 and higher only. 5 table 8-12. swap instructions mnemonics operands description issue latency xchg e rd, rx, ry exchange register and memory. 2 table 8-13. system register instructions mnemonics operands description issue latency mfdr e rd, sysregno move debug register to rd. 1 mfsr e rd, sysregno move syst em register to rd. 1 mtdr e sysregno, rs move rs to debug register. 1 mtsr e sysregno, rs move rs to system register. 1/3 musfr c rs move rs to status register. 1 mustr c rd move status register to rd. 1 table 8-14. system control instructions mnemonics operands description issue latency frs c invalidate the return address stack. 1
84 32002f?03/2010 avr32 8.18 read-modify-wr ite instructions this group contains instructions that perform atomical bit-operations on memory addresses. these instructions require multiple cycles insi de the memory controller, but these can be per- formed in parallel with subsequent instructions if the following instructions are not memory access instructions. a rmw instruction performed on an address in the iram section executes in a single cycle if the iram write buffer is empty. if the write buffer is not empty, two cycles are required. the pro- grammer can make sure the buffer is empty by ensuring that the instruction immediately before the rmw instruction is not a store or another rmw instruction. if the rmw instruction is performed on an addr ess in the hsb section, four cycles are needed for the rmw instruction to be executed. therefore, if another instruction attempts to access memory within one of the three following clock cycle s, up to three stall cy cles will be inserted. if a memory access instruction is scheduled less than 3 cycles after the rmw to hsb instruction, 3-n stall cycles are inserted. here n is the number of cycles used by instructions between the rmw instruction and the first memory access in struction. rmw operation s to the hsb section will take additional cycles if the hsb inserts wait states. when using rmw instructions, try to schedule code so that stall cycles are avoided. 8.19 code example 8.19.1 assumptions in the example code given in this chapter, the following assumptions are made: r0 points to an address in the iram space. iram is an alias for r0. r1 points to an address in the hsb or boot space. hsb is an alias for r1. all memories and buses have 0 wait state access. the cpu is in a priviliged mode, so that no privilege violations occur pref e rp[disp] prefetch cache line. 1 sleep e op8 enter sleep mode. 1 sync e op8 flush write buffer. 1 table 8-14. system control instructions table 8-15. read-modify-write instructions to iram section mnemonics operands description execution cycles iram execution cycles hsb memc e imm, bp clear bit in memory. 1/2 4 mems e imm, bp set bit in memory. 1/2 4 memt e imm, bp toggle bit in memory. 1/2 4
85 32002f?03/2010 avr32 all instructions are executed in the precise sequence shown below instruction cycles description add r5, r0 1 sub r5, r5 1 ssrf avr32_sreg_c 1 ssrf avr32_sreg_gm 3 ssrf to bits 31-16 takes 3 cycles max r6, r1, r0 1 mul r5, r1 1 mac r5, r1 1 1 cycle since r5 is al ready in the accumulator cache mac r3, r1 2 2 cycles since r3 is not in the accumulator cache mac r3, r1 1 1 cycle since r3 is not in the accumulator cache macs.d r2, r1, r2 4 4 cycles since register pa ir r3:r2 is not in the accumulator cache mulwh.d r6, r5, r1:t 1 48 bit result calculated and written back in 1 cycle st.w iram[0], r6 1 divs r4, r5, r6 35 ld.w r8, iram++ 2 load with pos tincrement takes two cycles satadd.w r4, r8, r9 1 ld.w r4, iram[4] 1 add r4, r4 1 no data hazard after loads from iram ld.w r5, iram[8] 1 ld.w r6, iram[12] 1 loads from iram can be adjacent without any stalling ldm iram++, r5, r6, r7, r8 5 ldm from iram ta kes 1+n= 5 cycles when loading 4 registers mfsr r8, avr32_sreg 1 cbr r8, 0 1 mtsr avr32_sreg, r8 3 mtsr to sreg takes 3 cycles, 1 cycle requir ed for other sysregs st.w iram[0], r5 1 st.w iram[4], r6 1 stores to iram can be adjacent without any stalling nop 1 nop takes 1 cycle ld.w r5, hsb[0] 2 reading from memories on the bus takes 2 cycles ld.w r6, hsb[4] 2 hsb bus reads are no t pipelined, each read takes 2 cycles st.w hsb[8], r6 1 hsb store done in background if 2 next insn is not mem access add r5, r6 1 nonmem insn scheduled after hsb store to avoid stall and r7, r8 1 nonmem insn scheduled after hsb store to avoid stall st.w hsb[8], r6 2 first of consecutive hsb stores requires extra cycle to start st.w hsb[12], r7 1 consecutive hsb stores are pipelined. st.w hsb[16], r8 1 consecutive hsb stores are pipelined. add r5, r6 1 consecutive hsb stores followed by 1 nonmem insn do not stall
86 32002f?03/2010 avr32 ldm hsb++, r5, r6, r7, r8 9 1+n=1+2r where r=#regs when reading from hsb addresses stm hsb, r5, r6, r7, r8 6 1+n=1+(1+r) where r=#regs when writing to hsb addresses add r6, r5 1 instruction not using the write buffer memc iram, 3 1 requires only one cycl e because write buffer was empty st.w iram[4], r8 1 instruction filling the write buffer memc iram, 3 2 requires 2 cycles becau se write buffer was not empty mul r5, r9 1 memc hsb, 7 4 next instruction has a memory access, 3 stall cycles needed ld.w r4, iram[16] 1 memc hsb, 7 1 memory not accessed in the 3 following clock cycles, no stall sub r7, r4 1 mul r6, r9 1 or r5, r8 1 instruction cycles description
87 32002f?03/2010 avr32 9. ocd system 9.1 overview the avr32 cpu is targeted at a wide range of 32 -bit applications. the cpu can be delivered in very different implement ations in various asic?s, assp?s, and standard parts to satisfy require- ments for low-cost as well as high-speed markets. according to the cost sensitivity and complexity of these applications, a similar span in debug complexity must be expected. while some users expect very simple debug features, or none at all, others will demand full-speed trace and rtos debug support. this also applies to the debug tools: while the simplest devel- opment takes place on simulators and development boards, most will require basic on-chip debug emulators, and a few will require complex emul ators with full-speed trace. to match these criteria, the avr32 ocd system is designed in accordance with the nexus 2.0 standard (ieee-isto 5001 ?-2003), which is a highly flex ible and powerful open on-chip debug standard for 32-bit microcontrollers. 9.1.1 features nexus compliant debug solution ocd supports any cpu speed execute debug specific cpu instructions (debug code) from program memory monitor or external debugger debug code can read and write all registers and data memory debug code can communicate with debugger through the debug port debug mode can be entered by external command, breakpoint instruction, or hardware breakpoints six program counter hardware breakpoints are supported two data breakpoints are supported breakpoints can be configured as watchpoints (flagged to the external debugger) hardware breakpoints can be combined to give break on ranges real-time program counter branch tracing real-time data trace real-time process trace nexus class 2+ 9.1.2 ocd controller overview the ocd system interfaces provides the exte rnal debugger with access to the on-chip debug logic through the jtag po rt and the auxiliary (aux ) port, as shown in figu re 9-1. the operation is described briefly below and in mo re detail in separate chapters. 9.1.2.1 host, debugger, and emulator at the host side, the user debugs his software using a source level debugger, which can read his compiled and linked object code. the source leve l debugger accesses features in the emulator and ocd system through an api (defined by the vendor or based on the nexus recommenda- tions), which constitutes the abstract inte rface between the source level debugger and the emulator. the api translates high-level functi ons, such as setting breakpoints or reading mem- ory areas, to sets of low level commands understood by the ocd controller. certain operations
88 32002f?03/2010 avr32 (such as reading the register file) may require running sections of debug code on the cpu, which can also be handled in this level. the em ulator translates the communication from the host into commands transmitted to the target ov er the jtag port. if trace is enabled, trace mes- sages are transmitted from the device on the nexus-defined au xiliary (aux) port. the aux port can be scaled to the number of output pins needed to sustain the estimated bandwidth require- ment. the nexus protocol defines the format of the messages and signals, the pin count options and pinout of the debug port, and the type of connector used. figure 9-1. block diagram of the ocd system (s haded) and its ma in connections. 9.1.2.2 accessing the debug features a number of blocks handle the various debug functions specified by the nexus standard. the emulator communicates with registers in these bl ocks by commands on t he jtag port, as spec- ified by the nexus standard. ocd registers are typically used for configuration, control, and status information. trace information and debug events can also generate messages to be transmitted on the aux port. registers are indexed and are accessed through read register and write register messages from the emulator. alternatively, they can be accessed by the cpu through mtdr and mfdr instructions, which gives a debug monitor in the cpu access to most of the debug features in the ocd system, as described in ?ocd register access? on page 98 . ocd system emulator tap aux port cpu data trace program trace transmit queue flow control unit ocd control signals debug inst breakpoint unit watchpoint msg trigger trigger breakpoint ownership trace unit ownership trace message cpu observation units debug status msg branch trace message data trace msg service access bus (sab) cpu observation signals pc comparators data comparators jtag port service access port (sap) host
89 32002f?03/2010 avr32 9.1.2.3 transmit queue trace and watchpoint messages are inserted into the transmit queue (txq) before being trans- mitted on the aux port. this provides some flexibility between the peak rate of trace message generation and the average rate of message transmission on the aux port. 9.1.2.4 flow control unit the flow control unit (fcu) ca n bring the cpu into and out of debug mode, and control the cpu operation in debug mode. the behavior is controlled by accessing ocd registers. debug mode can be configured as ocd mode or monitor mode. in ocd mode, the cpu fetches instructions from the debug instruction register. if the register is empty, the cpu is halted. in monitor mode, the cpu fetches debug instructions from a monitor code in the program memory, and the debug instruction register is not used. the fcu also handles single stepping by returning the cpu to normal mode, letting the cpu fetch one instruction from the program memory, and then returning to debug mode on the fol- lowing instruction. 9.1.2.5 breakpoint modules a number of instruction and data breakpoint modules can be configured for run-time monitoring of the instruction fetches and data accesses by the cpu. the modules can report if the moni- tored operation matches a predefined address, alternatively, also a data value. the modules operate on virtual addresses. a breakpoint will bring the cpu into debug mode. watchpoints are reported to the debugger, but does not affect cpu operation. a watchpoint can also be configured to start or stop data and program trace. the breakpoint modules can be combined to produce a watchpoint or breakpoint. complex breakpoint/watchpoint conditions are supported, e.g. trigger when a specific procedure writes a certain variable with a specific value. 9.1.2.6 program and data trace the program trace unit sends branch trace me ssages to the debugger, which allows the pro- gram flow to be reconstructed. to keep the amount of debug information low to save bandwidth, only change of program flow are reported (such as unconditional branches, taken conditional branches interrupts, exceptions, return operations, and load operations with pc as destination), hence the term "branch tracing". messages are typically relative to the previously transmitted message, to be able to compress information as much as possible. thus, the trace messages are sent out in temporal order, and regularly, synchronization messages with uncompressed, absolute addresses, are transmitted in case synchronization is lost. the data trace unit similarly traces data accesses , for read or write accesses, or both. similar relative address compression and synchronization schemes are used for data trace messages. since new trace messages can be generated bef ore the previous ones have been transmitted, all trace messages are queued before being transmitted by the aux interface. if the queue over- flows, the cpu can be halted to avoid losing trace information, or an error message followed by synchronization trace me ssages will be transmitted. 9.1.2.7 os debug support applications developed on an os platform places special requirements on the ocd controller and the debug software. for high -level debugging, the user will want to see which process is
90 32002f?03/2010 avr32 running at any time, without having to interrupt the cpu or trace the program flow. this is accomplished through ownership trace messaging, in which the process id of the running pro- cess is reported at every process switch. the cpu writes the process id to an ocd register in the ownership trace unit, which in turn generates an ownership trace message. 9.1.2.8 timestamps the emulator can tag events with a timestam p when they are extracted from the ocd system and transmitted to the emulator, to provide timing information for these events when they are transmitted to the debug host. however, due to the delay of the transmit queue and transmit time over the aux port, this timing will have limited accuracy. to compensate for this, the evto pin can be configured to toggle every time a message is inserted into the transmit queue, thus indi- cating very precisely when each event occu rs. the emulator would then store a queue of timestamp tags with each event, and associate each tag with the corresponding message, as they are extracted on the aux port. 9.2 cpu development support the ocd system can bring cpu into and out of debug mode, and control the cpu operation in debug mode. the behavior is controlled by ocd register configuration, stop commands from the debugger, or breakpoints. the ocd register s can be accessed by nexus messages or from the cpu as memory-mapped registers. 9.2.1 debug mode debug mode is an execution mode dedicated to application debugging and is not intended for running application code. debug mode can exec ute a debug code either from an external debugger through the ocd system (ocd mode), or from a debug routine in program memory (monitor mode). the de bug code will typically read out system registers and information about the various processes running in the system before restarting. the nexus class 2+ compliant ocd system contains breakpoint and trace modules, and other features for debugging code on the cpu. these fe atures are generally accessible both in ocd mode and monitor mode. in ocd mode, the debugger accesses the features through messages over the aux debug port, and in monitor mode, the cpu accesses the features through mtdr and mfdr instructions. the ocd system runs at system speed to stay synchronous with the cpu at all times. if the cpu is in a low-power sleep mode, it is woken up before entering debug mode. 9.2.1.1 operations in debug mode debug mode is characterized by the debug (d) bit in the status register (sr) in the cpu. debug mode is a privileged mode, and all legal instructions and memory operations are permit- ted illegal opcodes or memory operations which would normally cause an exception will be ignored in debug mode. the debug mode has a dedicated link and retu rn status register (rar_dbg and rsr_dbg, respectively) but no other masked registers. rar_dbg and rsr_dbg are not observable as part of the register file, only as system registers. the register file view is mapped according to the mode bits in the status register (m[2:0]). these bits are set to the exception context when entering debug mode, but can be changed freely within debug mode by writing to sr. in this way, different register contexts can be observ ed and modified, while maintaining the execution and access privileges of debug mode.
91 32002f?03/2010 avr32 debug mode is exited by the retd instruction, both in monitor mode and ocd mode. this restores pc from rar_dbg and sr from rsr_dbg. 9.2.1.2 a typical debug session flow figure 9-2 shows an example of a typical flow in debug mode. a software or hardware break- point aborts the execution of an instruction and causes debug mode to be entered. if the monitor mode (mm) bit in the development control (dc) ocd register is set, monitor mode is entered, and the cpu jumps to the softw are debug monitor starting at evba+0x01c. otherwise, ocd mode is entered, and the cpu stalls while waiting for instructions to be entered by the external debugger through the debug instruction (dinst) ocd register. in either case, the d bit in the cpu status register is set during the whole de bug session, giving access to all privileged oper- ations. any number of instructions can be executed before returning to the breakpointed instruction by the retd instruction. rar_dbg stores the address of the breakpointed instruction, and manipulating rar_dbg in debug mode is useful if a different return address is desired (for instance, to avoid repeated hits on a breakpoint instruction). figure 9-2. example of flow in debug mode . 9.2.2 monitor mode if the monitor mode (mm) bit in the development control register (dc) is set, the cpu will enter debug mode in monitor mode. instructions are fetched from the monitor code located in the pro- gram memory at the exception vector ba se address (evba) + 0x01c. the monitor code contains the necessary mechanisms to read and modify cpu and system registers, and memory user code breakpointed instruction software debug monitor sr:d = 1 evba+0x300 dc:mm? 1 = monitor mode 0 = ocd mode lr_dbg instructions from external debugger sr:d = 1 debug mode retd retd external debugger dinst in s t write register commands
92 32002f?03/2010 avr32 areas. all other exceptions and interrupts are masked by default when entering monitor mode, but the monitor code can explicitly unmask interrupts to allow critical interrupts to be serviced while the system is being debugged. the monitor code will typically communicate with an external debug tool, or (in cases of advanced systems like pda?s) a debug tool runni ng within the application (self-hosted debug- ger). communication with the external tool may take place over any communication link present in that device (e.g. usb, rs232), if such a communication line can be reserved for debug purposes. alternatively, the debug communication mechanism in the ocd system can be used to commu- nicate between the cpu and emulator over the jtag port. this is a set of ocd registers which can be written by the cpu or emulator, allowing a communication protocol to be developed in software. this mechanism can be used in any privileged cpu mode, including ocd mode. monitor mode is exited with the retd instruction. 9.2.2.1 debugging a monitor code each execution mode has a mask bit in sr, whic h indicates if a request to enter that mode will be taken or masked. the default priority of modes are reflected in these bits: when entering an execution mode, modes of the same or lower priority are masked. privileged modes can over- ride the mask, to dynamically change priorities (e.g. to allow critical interrupts to be serviced). by default, debug mode has priority above all other execution modes. this implies that any supervisor or user code can be interrupted by debug mode. other modes can be explicitly unmasked by a monitor code to allow critical in terrupts to be serviced. by default, debug mode is masked by the debug mask (dm) bit in sr when executing in monitor mode. the monitor mode can stack away the rar_dbg and rsr_dbg and then explicitly clear the dm bit to enable debug mode to be re-entered. if a debug exception occurs in monitor mode, the ocd system will bring the cpu into ocd mode, even if the mm bit is set. this allows monitor mode programs to be debugged. 9.2.3 ocd mode if the monitor mode (mm) bit in the development control register (dc) is cleared, the cpu will enter debug mode in ocd mode. when the cpu is in ocd mode, the debug status (dbs) bit in the development status (ds) register is set, in addition to the d bit in sr in the cpu. ocd mode is similar to monitor mode, except that instructions are fetched from the ocd system. ocd instructions are loaded by the debug tool by writing the opcode to the debug instruction register (dinst). once an inst ruction is written to dinst, th e cpu will fetch it, and the instruc- tion complete bit in ds (ds:inc) will be cleared until the cpu has comple ted the oper ation. the cpu is then halted until dinst is written again. the first instruction entered must be aligned to the msb of dinst. a sequence of instructions can be entered to dinst one word at a time, in the same sequence they would appear in pro- gram memory, i.e. they do not need to be word aligned. if the upper halfword of an extended instruction is written to the lower halfword of dinst, the lower half word of the instruction is writ- ten as the upper halfword of dinst in the next access. if the last instruction in a sequence is written to the upper halfword of dinst, the lowe r halfword should be written with a nop opcode. see figure 9-3 for an illustration of a sequence of operations used to execute instructions in ocd mode.
93 32002f?03/2010 avr32 any instruction valid in monitor mode is also valid in ocd mode. memory operations can be con- ducted without any special synchronization with external hardware. all ocd units can be configured while the cpu executes in ocd mode, but the following debug features are disabled: pc breakpoints data breakpoints watchpoints program trace data trace ocd mode is exited by writing the retd instruction to dinst. figure 9-3. executing instructions on the cpu in ocd mode . 9.2.4 entry into debug mode debug mode can only be entered when the ocd is enabled, and debug mode is not masked. the following ways of entr y are then possible: debug request from the debugger program counter breakpoint data address or value breakpoint breakpoint instruction trapping opcode 0x0000 single step event on evti pin abort command from the debugger the debugger can identify the condition which caused entry into debug mode by examining the status bits in the development status register (ds). each cause of entry has a particular bit associated with it. several exceptions can tri gger simultaneously, causing more than one bit to be set. note that any privileged cpu mode may write the sr:d bit to one directly, but this will not cause entry to debug mode. ocd instructions mov r12,r7 sub r12,0x01 mov r6,r12 adc r6,r12,r7 retd opcode 0x0e9c 0x201c 0x1896 0xf807 0046 0xd623 written by tool to dinst 0x0e9c201c 0x1896f807 0x0046d623 changes in ds inc 0 1 inc 0 1 inc 0 1 dbs 0
94 32002f?03/2010 avr32 9.2.4.1 debug request the debugger may want to stop cpu operation, unrelated to current instruction execution, e.g. if the user presses a "stop" butt on in the debug tool gui. the debugger will then write the debug request (dbr) bit in the development control register (dc). this causes the cpu to enter debug mode on the next instruction to be executed, before execution. 9.2.4.2 program counter breakpoint the program counter breakpoints can be configured to halt the cpu when executing code at a specific address, or address range. this will cause the cpu to be halted before the break- pointed instruction is executed. the ignore first match (ifm) bit in the development control (dc) register should be written to one before exiting debug mode, to avoid re-triggering the program breakpoint. this bit only pre- vents program breakpoints from re-triggering. if the instruction causes a breakpoint for another reason (e.g. a breakpoint instruction or a data breakpoint), debug mode will be re-entered. 9.2.4.3 data address or value breakpoint cpu memory accesses can be monitored by data breakpoint comparators in the ocd system. if the access matches a set of predefined conditions (e.g. address, value, or access type), debug mode is entered after the memory operation completes, but before the next instruction is executed. data breakpoints are precise, halting on the instruction immediately after the memory operation which caused the breakpoint. the cpu will return to the first non-executed instruction when a retd is executed. 9.2.4.4 breakpoint instruction the breakpoint instruction is programmed along with the object code into the program memory or instruction cache, and is decoded by the cp u. when this instruction is scheduled for execu- tion and debug mode is enabled, the cpu will enter debug mode. if debug mode is disabled (e.g. masked by the dm bit in the status register, or dbe in dc is zero), the breakpoint instruc- tion will execute as a nop (no operation). for devices based on volatile program memory, the breakpoint instruction can be dynamically inserted into the code by the debug tool, enabling an unlimited number of program breakpoints in the code. this involves replacing an ex isting opcode with a breakpoint instruction. the replaced opcode has to be re-inserted before exiting debug mode. note that this is only possible in ocd mode. for devices based on non-volatile program memory, the breakpoint instruction can be statically compiled or linked into the code before downloading, marking all points the program can be halted. debug mode will be entered for all br eakpoints (if debug mode is enabled), and the debugger would return immediately if it does not want to halt at a particular breakpoint location in the code. the breakpoint will be taken before the breakpoint instruction is actually executed. this has the effect that the cpu will return from debug mode to the same breakpoint instruction, re-entering debug mode immediately, unless the ocd system is configured to modify the return address or replace the breakpoint instruction from the instruction flow. the ifm bit does not have an effect when debug mode returns to a breakpoint instruction.
95 32002f?03/2010 avr32 9.2.4.5 trapping opcode 0x0000 in flash-based microcontrollers, the opcode 0x0000 can overwrite any other opcode without having to erase and reprogram the flash. therefore this instruction can enter debug mode, as for the breakpoint instruction. however, the opcode 0x0000 is also a valid part of the instruction set (add r0,r0 in avr32) and can be part of the software to be debugged. therefore, the user must write the dc:toz (trap opcode zero) bit to one to enable this feature. the ds:boz bit will be set if debug mode is en tered due to a trapped 0x 0000 instruction. the debugger must then identify whether this opcode belongs to the original object file or has been inserted by the debugger as a software breakpoint. if it was part of the object file, the debugger should use the instruction replacement to return to the program, and insert the 0x0000 opcode in dinst. executing 0x0000 during instructio n replacement only performs an add r0,r0 oper- ation without re-entering debug mode. 9.2.4.6 single stepping the debugger will typically allow th e user to step throug h the application source or object code, line by line. this single stepping can be either of step-into or step-over type. step-into will exe- cute exactly one instruction and halt the cpu at t he start of the next instruction, regardless of whether this instruction is part of the main program, subroutine, interrupt, or exception. step- over will execute the current inst ruction and any lower-level even ts generated before the follow- ing instruction (including subroutines, interrupts, and exceptions). step-over in the object code and all single stepping in the source code are implemented by con- figuring a program breakpoint on the address of the next object code instruction where the debugger expects to halt.s step-into is implemented in ocd hardware and is controlled by the single step (ss) bit in the development control register. when debug mode is exited by retd, exactly one instruction from the program memory will be exec uted before deb ug mode is re-entered. this mechanism works identically for ocd and monitor mode. 9.2.4.7 event on evti pin if the event in control (eic) bits in dc are written to 0b01, a high-to-low transition on the evti pin will generate a breakpoint. evti must stay low for one cpu clo ck cycle to guarantee that the breakpoint will trigger. the external breakpoint (exb) bit in ds will be set when a breakpoint is entered due to an event on the evti pin. 9.2.4.8 abort command some software errors could cause the cpu to get stuck in a state which does not allow debug mode to be entered through the mechanisms described above. an example is if a privileged mode writes sr:dm to one, without clearing the bit. to prevent the debugger from hanging indefinitely, the debugger can write the dc:abort bit to one after some timeout period, and force the cpu to enter debug mode. the abort command behaves identical to a debug request, except t hat the dm bit and any pending exception will be ignored, regardless of exception priority. the rar_dbg and rsr_dbg will reflect the last non- executed instruction, which can aid in locating the error. if debug mode is entered due to an abort command, ds:dba will be set, as for debug requests.
96 32002f?03/2010 avr32 9.2.5 exceptions and debug mode debug mode has priority over any execution mode, so that breakpoints can be set in exception and interrupt routines. however, if a breakpoint is set on an instruction which triggers a critical exception, the breakpoint is flushed. critical exceptions are exception which are asynchronous to the cpu (interrupts), exceptions which in validate the currently fetched instruction (e.g. instruction address exceptions), and exceptions which indicate that the system has become unstable and should abort the program flow (e.g. bus error). the complete list of exceptions with higher priority than debug mode are listed in the exception chapter in the avr32 architecture manual. if a pc breakpoint, a breakpoint instruction, or a trapped 0x0000 opcode is flushed by an excep- tion, debug mode will not be entered. if another type of breakpoint has triggered, debug mode will be entered on the first instru ction in the exception handler. in the rare cases where the first instruction in a critical exception also triggers a critical exception (e.g. if evba is set incorrectly, triggering an infinite loop of in struction address exceptions), the debugger must write the dc:abort bit to one to halt the cpu and enter debug mode to identify the error. 9.2.6 instruction replacement a convenient way of implementing an unlimited number of instruction breakpoints is letting the debugger replace an instruction by a breakpoint instruction. this mechan ism is only available in ocd mode on devices implemented with writeable program memory or writeable instruction cache. if this instruction executes, debug mode will be entered, and the debugger identifies the breakpointed location. when returning, the breakpoint instruction must be replaced by the origi- nal instruction. the debugger will write the instruction replace (irp) bit in dc and the appropriate instruction in the debug instruction register and its corresponding pc value in the debug program counter (dpc). when retd is executed, pc and sr are restored, but one more instruction is fetched from the ocd system before returning to fetching from program memory. note that instruction replacement operates on word boundaries. the debugger must store the whole word containing the replaced opcode before inserting the breakpoint instruction. also note that dpc should always be written when performing an instruction replacement to ensure the correct instruction is executed. the debugger will t hen perform the following sequence when exiting ocd mode. note that rar_dbg is accessed through executing cpu instructions through the debug instruction regis- ter (dinst). the same sequence can be used both for compact and extended instructions, regardless if the extended instruction is unaligned (in which case only the upper halfword of the instruction is replaced). 1. write rar_dbg to the debug program counter. 2. increment rar_dbg by 2 or 4, so the register points to the start of the next word in the program memory. 3. write 1 to instruction replace (irp) in dc. 4. write a retd instruction to dinst. the cpu will ex it debug mode and stall while waiting for new instructions. 5. write the stored word to dinst. this instruction is fetched by the cpu, and the cpu continues normal program execution.
97 32002f?03/2010 avr32 9.2.6.1 instruction replacement example table 9-1 shows an example of a code where the user wants to insert a breakpoint. the tool wants to insert a software breakpoint on the instruction "adc r6,r12,r7" on pc=0x000016. this is an extended instruction, and only the upper halfword needs to be replaced by the breakpoint instruction. 1. the upper halfword is contained within the word located at 0x000014, and the debug tool stores this value (0xc0acf807). 2. the debugger writes a breakpoint instruction (opcode 0xd673) to location 0x000016 in the cpu?s program memory to replace the most significant word of the breakpointed instruction. 3. when the breakpoint instruction execut es, the cpu will enter ocd mode, and ds:dbs and ds:swb are set, indicating that ocd mode is entered due to a software breakpoint. 4. the tool performs a normal sequence of operation in ocd mode. 5. when the tool is ready to return to normal cpu operation, it reads the rar_dbg value to find the return address. 6. the tool inserts cpu instructions to dins t to increment rar_dbg by 2, so it is aligned to the next word in the program memory. 7. the tool inserts a "retd" instruction to di nst. the tool will receive a debug status mes- sage, which indicates that the cpu has exited ocd mode, and is now waiting for one more instruction from the tool. 8. the tool writes the return address (0x000016) to the debug program counter (dpc). 9. the tool looks up the stored instruction word (based on the return address) and writes this value (0xc0acf807) to the debug instruction register (dinst). the cpu now resumes normal operation. 9.2.7 sleep mode if the cpu is in sleep mode, it will not receive clocks nor resp ond to an ocd re quest from the debugger. thus, if the debug request bit in dc is written to one while the cpu is in sleep mode, the cpu will automatically return to active mode. the instruction following the sleep instruction will be tagged with an ocd except ion, and the cpu will jump dire ctly to debug mode. the nor- mal debug procedure can be followed while executing in debug mode. if debug mode is entered from sleep mode, the st op status (stp) bit in the develo pment status register will be set. when returning from de bug mode, the cpu will by default retu rn to the instru ction following the sleep instruction. the debugger can handle this situation in two ways: ignore the problem, effectively waking the cpu from sleep mode on a debug request. table 9-1. example of a user code section pc value opcode instruction 0x000010 0x0e9c mov r12,r7 0x000012 0x201c sub r12,0x01 0x000014 0xc0ac rcall label1 0x000016 0xf8070046 adc r6,r12,r7 0x00001a 0x2027 sub r7,0x02
98 32002f?03/2010 avr32 decrement rar_dbg in debug mode to return to the sleep instruction. this places the cpu back into sleep mode after exiting debug mode. 9.2.8 ocd register access the ocd registers control the ocd system. thei r specification is based on the nexus recom- mended registers as outlined in the nexus standard specification [ieee-isto 5001?-2003]. all registers can be accessed through the jtag interface. 9.2.9 ocd features in debug mode when the cpu executes in debug mode, certain ocd features will be disabled. the following table indicates how the various ocd features will behave in debug mode. for more information on the specific features, please see the indicated page. 9.2.10 ocd registers accessed by cpu a monitor program running on the target can access the ocd registers through mtdr and mfdr instructions. these instructions transfer data between a register in the register file and an ocd register, according to the register index given in ?ocd register summary? on page 153 . these instructions can also be used in ocd mode to transfer information from the register file and sys- tem registers to the debugger, through the debug communication mechanism. 9.2.11 runtime write access to ocd registers the ocd registers can always be accessed by jtag when the when the ocd system is not enabled or the cpu is in ocd mode. the ocd registers can also be read by jtag at any time, and by the cpu in any privileged mode. when the cpu is in other modes - either running normal code, or executing in monitor mode - the ocd registers can be written by jtag as specified in table 9-3. if the registers are accessed in another way than specified, undefined operation may result. the ocd register protect (orp) bit in dc define the allowed write access to ocd registers in privileged modes. if the orp bit in dc does not allow cpu access to ocd registers in the cur- table 9-2. ocd features in debug mode feature available in debug mode? program breakpoints (hw) yes, in monitor mode when sr:dm is cleared software breakpoints yes, in monitor mode when sr:dm is cleared data breakpoints yes, in monitor mode when sr:dm is cleared watchpoints (program and data) yes, in monitor mode program trace no data trace no ownership trace yes debug communication mechanism yes
99 32002f?03/2010 avr32 rently executing mode, only pid and dccpu can be written. illegal access to the registers will be ignored with no error reporting. 9.2.12 ocd interrupts to support custom debug protocols running in software the ocd system support giving inter- rupts to the cpu when dcemu is written or when dccpu is read. a software protocol handler can then be triggered by these interrupts instead of having to poll dcsr to see if the data in dccpu or dcemu has been read or written. to enable these interrupts the user must do the following: program the interrupt controller with the correct priority and handler address for the interrupt. enable the interrupts from the ocd by setting the corresponding bits in dccr table 9-3. ocd register access register can be written by jtag while cpu is running? can be written by cpu in monitor mode? development control (dc) yes yes watchpoint trigger (wt) yes yes data trace control (dtc) can be written to disable / enable trace channels. ye s data trace start address (dtsa) channel 1 to 2 can only be written while trace channel is disabled ye s data trace end address (dtea) channel 1 to 2 can only be written while trace channel is disabled ye s pc breakpoint/watchpoint control (bwc) can be written to disable / enable watchpoints / breakpoints. yes, if sr:dm is set. data breakpoint/watchpoint control (bwc) can be written to disable / enable watchpoints / breakpoints. yes, if sr:dm is set. pc breakpoint/watchpoint address (bwa) can only be written while breakpoint / watchpoint is disabled yes, if sr:dm is set or breakpoint disabled. data breakpoint/watchpoint address (bwa) can only be written while breakpoint / watchpoint is disabled yes, if sr:dm is set or breakpoint disabled. breakpoint/watchpoint data (bwd) can only be written while breakpoint / watchpoint is disabled yes, if sr:dm is set or breakpoint disabled. ownership trace process id (pid) yes yes debug instruction register no no debug program counter no no debug communication cpu (dccpu) yes yes debug communication emulator (dcemu) yes yes
100 32002f?03/2010 avr32 turn off the interrupt masks in the cpu when an interrupt occurd the cpu will jump to the interrupt handler routine and process the interrupt. the interrupt handler must clear the interrupt before leaving this routing. this is done by witing a zero to dcemudi or dccpuri fo r dcemu reads and dccpu writes respectively: 9.2.13 messages 9.2.13.1 debug status (debs) this message is output when the cpu enters or exits debug mode or a low-power mode. the message is output whenever the aux port is enabl ed. the status field of this message con- tains the information in the de velopment status register. the field will contain these values: the cpu enters debug mode: status bits indicate cause of entry to debug mode. dbs is set if ocd mode was entered. the cpu exits debug mode: status = 0. this includes exiting debug mode by writing dc:res. the cpu enters a low-power mode: only the stp bit is set, while the other bits are zero. the cpu exits a low-power mode: status = 0 9.2.14 registers 9.2.14.1 device id register (did) the device id register (did) provides key attr ibutes to the developmen t tool concerning the embedded processor. this is the same as the value returned by the jtag id instruction. 9.2.14.2 nexus configuration register (nxcfg) the nexus configuration register (nxcfg) provides key information about the specific imple- mentation of the cpu and ocd architecture, and the configuration of the nexus development table 9-4. debug status debug status message packet size packet name packet type description 32 status fixed the contents of the development status register. 6tcodefixedvalue = 0 table 9-5. did register r/w bit number field na me init. val. description r 31:28 rn part specific rn - revision number r 27:12 pn part specific pn - product number r 11:1 mid 0x01f manufacturer id 0x01f = atmel r 0 reserved 1 reserved this bit always reads as 1
101 32002f?03/2010 avr32 features on this device. this information is static, and may be used to develop generic nexus debuggers which will work across a family of avr32 devices with different nexus configurations. 9.2.14.3 debug communication cpu register (dccpu) if the cpu wants to transmit data to the debugger tool, it writes data to the debug communica- tion cpu register using mtdr. by writing this register, a dirty bit is set in the debug table 9-6. nexus configuration register r/w bit number field na me init. val. description r 31:29 reserved 0 r28 nxdma 0 direct memory access support 0 = not supported 1 = supported r 27:25 nxdtc 0 data trace channels 0 = not supported 1 = supported r24 nxdrt 0 data read trace support 0 = not supported 1 = supported r23 nxdwt 0 data write trace support 0 = not supported 1 = supported r22 nxot 0 ownership trace support 0 = not supported 1 = supported r 21 nxpt 0 program trace support 0 = not supported 1 = supported r 20:17 nxmdo 6 aux mdo pins 0 = no mdo or mseo pins n = n mdo pins, nxmseo mseo pins r 16 nxmseo 1 aux mseo pins 0 = 1 mseo pin 1 = 2 mseo pins r 15:12 nxdb 2 number of data breakpoints r 11:8 nxpcb 6 number of pc breakpoints r7:4 nxocd 0 ocd version 0000 = avr32ap ocd 0001 = avr32uc ocd other = reserved r 3:0 nxarch 0 architecture 0000 = avr32b 0001 = avr32a other = reserved
102 32002f?03/2010 avr32 communication status register. the emulator should poll the status register and read dccpu if the dirty bit is set. 9.2.14.4 debug communication emulator register (dcemu) when the emulator writes to this register, a dirty bit is set in the debug communication status register. the cpu can poll this bit to see if dcemu contains unread data.. 9.2.14.5 debug communication status register (dcsr) to avoid overruns the cpu must poll this register before writing a new value to dccpu. note that the bits in this register are not automatically cleared in ocd mode. this allows a debugger to update views and observe th e system without accidentally modifying the dcsr register. the ocd system can produce interrupts when the dcemu register has been updated and when the dccpu register is read. the cpuri and emudi flags are set on the interrupt events, but are cleared by software by writing the dcsr register. to enable the interrupts the corresponding bits in the dccr register has to be set and th e interrpt controller has to be programmed. table 9-7. debug communication cpu register r/w bit number field na me init. val. description r/w 31:0 data 0x0000_ 0000 data value data written by cpu table 9-8. debug communication emulator register r/w bit number field na me init. val. description r/w 31:0 data 0x0000_ 0000 data value data written by emulator table 9-9. debug communication status register r/w bit number field na me init. val. description r 31:4 reserved 0x0000_ 0000 reserved these bits are reserved, and will always read as 0 r/w 1 emudi 0 emulator data dirty interrupt flag 0 = dcemu has not been written to since the clearing of this bit. 1 = dcemu contains a new data value. this bit is cleared by writing this bit to 0.
103 32002f?03/2010 avr32 9.2.14.6 debug communication control register (dccr) to enable the dccpu read and dcemu dirty interrupts the corresponding enable bits must be set in this register. r/w 1 cpuri 0 cpu data read interrupt flag 0 = dccpu has not been read since the clearing of this bit. 1 = dcemu has been read. this bit is cleared by writing this bit to 0. r/w 1 emud 0 emulator data dirty 0 = dcemu has not been written to since last read from cpu. 1 = dcemu contains a new data value. this bit is cleared by reading dcemu. r/w 0 cpud 0 cpu data dirty 0 = dccpu has not been written to since last read from emulator. 1 = dccpu contains a new data value. this bit is cleared by reading dccpu. table 9-9. debug communication status register r/w bit number field na me init. val. description table 9-10. debug communication control register r/w bit number field na me init. val. description r 31:2 reserved 0x0000_ 0000 reserved these bits are reserved, and will always read as 0 r/w 1 dccpuimask 0 dccpu interrupt mask 0 = dccpu interrupts are disabled. 1 = dccpu interrupts are enabled. r/w 0 dcemuimask 0 dcemu interrupt mask 0 = dcemu interrupts are disabled. 1 = dcemu interrupts are enabled.
104 32002f?03/2010 avr32 9.2.14.7 development co ntrol register (dc) dc is used for basic development control of the cpu. table 9-11. development control register r/w bit number field na me init. val. description r/w 31 abort 0 abort writing abort to one while dbe is asserted causes the cpu to enter debug mode, regardless of sr:dm and any pending exceptions. if the cpu was in sleep mode, it will first be woken up before entering debug mode. the abort bit is cleared automatically when debug mode is entered. s30 res 0 res - application reset writing this bit causes an application reset, which will reset the cpu and ot her system modules. the ocd state machines will be reset and the transmit queue flushed, but the ocd control and configuration registers will not be cleared. r/w 29 mm 0 mm - monitor mode 1 = the cpu will enter debug mode in monitor mode 0 = the cpu will enter debug mode in ocd mode changing this bit in debug mode does not take effect until the cpu enters debug mode the next time. r/w 28 orp 0 orp - ocd register protect 0 = ocd registers can be written by any privileged cpu mode 1= ocd registers can be written only in debug mode r/w 27 rid 0 rid - run in debug 0: peripherals are frozen in debug mode 1: peripherals keep running in debug mode. in addition the pdbg register must be configured with individual masks for each module. r 26 reserved 0 r/w 25 toz 0 toz - trap opcode zero 0: the opcode 0x0000 is executed as a normal cpu instruction 1: the opcode 0x0000 causes entry to debug mode r/w 24 ifm 0 ifm - ignore first match when written to one, a pc breakpoint on the first instruction after exiting debug mode with the retd instruction will not trigger re-entry to debug mode. typically used when returning from a program breakpoint. this bit stays one until written to zero.
105 32002f?03/2010 avr32 r/w 23 irp 0 irp - instruction replace if irp is written to one before exiting ocd mode with the retd instruction, the fi rst instruction after exiting ocd mode will be fetched from the debug instruction register. this bit is cleared automatically after this fe tch takes place. this bit will not have any effect if written at the same time as res. r/w 22 sqa 0 sqa - software quality assurance 0: regular program trace 1: sqa enhanced program trace r/w 21:20 eos 0 eos - event out select 00 = no operation 01 = emit event out when the cpu enters debug mode 10 = emit event out for breakpoints/watchpoints 11 = emit event out for message insertion into the txq r 19:14 reserved r/w 13 dbe 0 dbe - debug enable dbe enables debug mode and all debug features in the cpu. dbe must be written to one to enable breakpoints, debug requests, or single steps. r/w 12 dbr 0 dbr - debug request writing dbr to one while dbe is asserted causes the cpu to enter debug mode. if the cpu was in sleep mode, it will first be woken up before entering debug mode. the dbr bit is cleared automatically when debug mode is entered. 11:9 reserved r/w 8 ss 0 ss - single step if ss is written to one before exiting debug mode with the retd instruction, exactly one instruction will be executed before returning to debug mode. ss stays one until written to zero by the debugger. table 9-11. development control register r/w bit number field na me init. val. description
106 32002f?03/2010 avr32 9.2.14.8 development status (ds) register this register is used to examine the debug stat e of the cpu and the cause for entering debug mode. note that multiple sources may trigger debug mode simultaneously, causing more than one bit to be set. the register is read-only. all bits are dynamic and do not require clearing. r/w 7:5 ovc 0 ovc[2:0] - overrun control ovc controls the action taken if branch, data, or ownership trace messages are generated while the transmit queue is full. settings 111 though 100 are reserved. 000 = generate overrun messages 001 = delay cpu to avoid btm and ownership trace overruns 010 = delay cpu to avoid dtm and ownership trace overruns 011 = delay cpu to avoid btm, dtm, and ownership trace overruns 111-100 = reserved r/w 4:3 eic 0 eic[1:0] - evti control the eic bits control the action performed when the evti pin on the nexus debug port receives a high-to-low transition. if trace is enabled, evti can be configured to cause a trace synchronization message. if debug mode is enabled, evti can be configured to cause a breakpoint. 00 = evti for program and data trace synchronization 01 = evti for breakpoint generation 10 = no operation 11 = reserved r/w 2:0 tm 0 tm[2:0] - trace mode the tm bits select which trace modes are enabled. 000 = no trace xx1 = otm enabled x1x = dtm enabled 1xx = btm enabled if data or branch tracing is triggered or stopped by a watchpoint , the dtm and btm bits are updated accordingly. table 9-11. development control register r/w bit number field na me init. val. description
107 32002f?03/2010 avr32 this register is undefined when the cpu is not in debug mode. table 9-12. development status register r/w bit number field name init. val. description r 31:29 reserved 0 r28 ntbf 0 ntbf -nanotrace buffer full this bit is set if debug mode is entered because the memory service unit has signalled that the nanotrace buffer is full. this bit is cleared when debug mode is exited. r 27 exb 0 exb -external breakpoint this bit is set if debug mode was entered due to an event on the evti pin. this bit is cleared when debug mode is exited. r26 dba 0 dba - debug acknowledge this bit is set if debug mode was entered due to setting the debug request or abort bit in the dc register. this bit is cleared when debug mode is exited. r25 boz 0 boz - break on opcode zero this bit is set if debug mode was entered due to opcode 0x0000 being executed. this bit is cleared when debug mode is exited. r24 inc 0 inc - instruction complete 0: the cpu is executing one or more instructions, or is not in ocd mode. 1: the cpu is in ocd mode and is not executing any instructions. r 23:16 reserved 0 r 15:8 bp[7:0] 0 bp - breakpoint status the bp bits identify which hardware breakpoint caused debug mode to be entered: bp[0]: bp0a bp[1]: bp0b bp[2]: bp1a bp[3]: bp1b bp[4]: bp2a bp[5]: bp2b bp[6]: bp3a bp[7]: bp3b these bits are cleared when debug mode is exited. r 7:6 reserved 0 r5 dbs 0 dbs - debug status dbs is set when the cpu is in ocd mode, otherwise cleared. this bit stays cleared also when the cpu operates in monitor mode.
108 32002f?03/2010 avr32 9.2.14.9 debug instruction register (dinst) the debug instruction register contains the instruction to be executed in ocd mode. the cpu fetches and executes the instruction faster than they can be written by the debug port. dinst is also used to store the instruction to replace the breakpoint instruction. 9.2.14.10 peripheral debug register (pdbg) the peripheral debug register controls the operation of modules in debug mode. if the dc.rid bit is set, the cpu is in debug mode and the pdbg bit for a module is set this module is kept running in debug mode. otherwise the module is stopped. the mapping between the bits in this register and modules are part specific and are described in the ocd module configuration sec- tion of the part datasheet. r4 stp 0 stp - stop status stp is set if ocd mode is entered from sleep mode. this bit can be used by the debugger to determine the proper return sequence from ocd mode. this bit is cleared when ocd mode is exited. r 3 reserved 0 r2 hwb 0 hwb - hardware breakpoint status this bit is set if debug mode was entered due to a hardware breakpoint. the bp[7:0] bits should be examined to determine the breakpoint(s) which triggered. this bit is cleared when debug mode is exited. r1 swb 0 swb - software breakpoint status this bit is set if debug mode was entered due to a breakpoint instruction being executed. returning from a software breakpoint may require special handling by the debugger. this bit is cleared when debug mode is exited. r 0 sss 0 sss - single step status this bit is set when debug mode is entered due to a single step. this bit is cleared when debug mode is exited. table 9-12. development status register r/w bit number field name init. val. description table 9-13. debug instruction register r/w bit number field na me init. val. description r/w 31:0 dinst 0 dinst - debug instruction the instruction to be executed on the cpu. table 9-14. debug instruction register r/w bit number field na me init. val. description r/w 31:0 pdbg 0 pdbg - peripheral debug. 0 = the peripheral is running in debug mode. 1 = the peripheral is stopped in debug mode.
109 32002f?03/2010 avr32 9.2.14.11 debug program counter (dpc) this register contains the pc value of the last executed instruction in any non-debug mode. this allows a debugger to sample program execution addresses for statistical purposes without inter- rupting the cpu. if this register is read in debug mode, it will reflect the last executed instruction before debug mode was entered. note that several types of br eakpoints trigger before an instruction is exe- cuted, so this value is not ne cessarily identical to rar_dbg. when replacing the retu rn instruction from de bug mode, the cpu will see the dpc value as the pc value for the executed instruction. the user only needs to write this register when replacing the return instruction from ocd mode. 9.3 debug port 9.3.1 overview the ocd debug port consists of the jtag port and the aux port. the low bandwidth jtag port handles all register access, while the high bandwidth aux port transfers all nexus messages from the ocd system. the nexus standard defines the maximum clock frequency for jtag to be 33 mhz, and for aux 200 mhz. 9.3.2 jtag access to ocd register is done through an ieee1149.1 jtag-port. the jtag tap controller is shared with the rest of the system. in order to enable access to ocd register the emulator must perform the following sequence. 1. put the tap controller in the state "test logic reset". 2. insert the ocd instruction to prepare the debug port to receive ocd register access. the ocd instruction is insert ed using the ir scan path. 3. use the dr scan path to insert the ocd register address and operation (read / write). 4. use the dr scan path to read / write the data to / from the register. 5. repeat 3 through 4 for every register operation. t he tap controller will remain in ocd mode until a test logic reset is detected. table 9-15. debug program counter r/w bit number field na me init. val. description r/w 31:0 dpc 0 dpc - debug program counter pc of the last executed instruction
110 32002f?03/2010 avr32 to be able to use jtag-based debug tools for avr32 without adapters, it is recommended that a circuit design using an avr32 device should us e a standard 10-pin 50-mil idc connector with the pinout shown in table 9-16. the signals are described in table 9-17. table 9-16. avr32 standard jtag connector pinout. all directions relative to processor signal dir pin pin dir signal tck in 1 2 gnd tdo out 3 4 out vref tms in 5 6 in reset_n n/c 7 8 n/c tdi in 9 10 n/c table 9-17. jtag signals pin direction description trst_n input asynchronous reset for th e tap controller and jtag registers tck input test clock. data is driven on falling edge, sampled on rising edge. tms input test mode select tdi input test data in tdo output test data out reset_n input device reset vref output reference voltage from target. signals should be driven relative to this voltage level.
111 32002f?03/2010 avr32 figure 9-4. jtag tap controller state diagram. 9.3.3 aux port the auxiliary (aux) port and messaging protocol follow the definitions of the nexus standard. this standard allows varying the number of si gnalling pins. the following configuration is selected for avr32uc. 6 data output pins (mdo) 2 message start/end output pins (mseo ) 1 evto pin 1 evti pin the configuration is based on the presumed needs for bandwidth in a system being traced at 100+ mips, balanced against the desire to keep debug pincount low. this configuration can be changed in future implementations to allow for greater or smaller bandwidth over the aux port. the aux pins may be multiplexed with gpio in a device. by default, the mcko, mdo, and mseo pins are tristated or used as gpio, and the nexus functionality must be explicitly enabled by the debugger. evto , evti , and the jtag pins are always available to the debugger. if the aux pins are needed for nexus functionalit y in an application, it is recommended not to use these pins for gpio purposes, as this can affect the signal integrity required for nexus operation. test-logic- reset run-test/ idle select-dr scan select-ir scan capture-dr capture-ir shift-dr shift-ir exit1-dr exit1-ir pause-dr pause-ir exit2-dr exit2-ir update-dr update-ir 0 1 1 1 0 0 1 0 1 1 0 0 1 0 1 1 1 0 1 1 0 0 1 1 0 1 0 0 0 0 0 1
112 32002f?03/2010 avr32 the complete signal list of the aux port is shown in table 9-18. table 9-18. auxiliary pins auxiliary pins width direct ion description mcko 1 o message clockout (mcko) is a free-running output clock to development tools for timing of mdo and mseo pin functions. mdo 6 o message data out (mdo[5:0]) are output pins used for all messages generated by the device. in single datarate mode, external latching of mdo shall occur on rising edge of mcko. in double datarate mode, external latching of mdo shall occur on both edges of mcko. mseo 2 o message start/end out (mseo[1:0] ) pins indicate when a message on the mdo pins has started, when a variable length packet has ended, and when the message has ended. in single datarate mode, external latching of mseo shall occur on rising edge of mcko. in double datarate mode, external latching of mseo shall occur on both edges of mcko. evto 1 o event out (evto ) is an output pin which can be configured to toggle every time a message is inserted into the transmit queue, when the cpu entered ocd mode, or when a breakpoint or watchpoint hit occured, as configured by the eos bits in the development control register . evti 1 i event in (evti ) is an input which, when a high-to-low transition occurs, a processor is halted (breakpoint) or program and data synchronization messages are transmitted from the ocd controller, as configured by the eic bits in the development control register. reset_ n 1 i system reset
113 32002f?03/2010 avr32 to be able to use aux-based debug tools for av r32, a circuit design using an avr32 device should use a mictor38 connector (amp p/n 7 67054-1) as defined in the nexus standard, with the pinout shown in table 9-19. 9.3.3.1 reset configuration the nexus standard specifies that the aux port can be enabled by keeping evti low while puls- ing trst (or exiting test-logic-reset). the ocd syst em in avr32 has removed this feature. in order to enable the aux port, the debugger has to write the axc:axe (auxiliary enable) bit. 9.3.3.2 message protocol the ocd system implements the auxiliary port message protocol defined in the nexus stan- dard. the following section is merely a summary of this protocol. for details, please see the nexus standard. messages are composed of a start-of-message (som) token, followed by one or more packets of information, each of fixed or variable length, and ended by an end-of-message (eom) token. som/eom and end-of-variable-length-pa ckets (evlp) are signalled by mseo for transmitted messages. packet information is carried by the mdo pins. the number of mdo pins available is known as the port boundary . the information carr ied by the mdo and mseo pins each cycle is known as a frame . table 9-19. avr32 standard nexus connector pinout. all directions relative to processor signal dir pin pin dir signal mseo0 out 38 37 n/c mseo1 out 36 35 n/c mcko out 34 33 n/c evto_n out 32 31 n/c mdo0 out 30 29 n/c mdo1 out 28 27 n/c mdo2 out 26 25 n/c mdo3 out 24 23 n/c mdo4 out 22 21 in trst_n mdo5 out 20 19 in tdi n/c 18 17 in tms n/c 16 15 in tck n/c 14 13 n/c vref out 12 11 out tdo evti_n in 10 9 in reset_n n/c 8 7 n/c n/c 6 5 n/c n/c 4 3 n/c n/c 2 1 n/c
114 32002f?03/2010 avr32 9.3.3.3 message rules mdo is valid whenever mseo does not indicate "idle". fixed length packets are implicitly recognized from the message format, and are not required to end on a port boundary. thus, packets may also start within a port boundary if following a fixed length packet. the end of variable length packets is identified through the mseo pins, and to identify the end of the packet uniquely, these packets must end on a port boundary. if neces- sary, the packet must be stuffed with zeroes to align the end to a port boundary. variable length packets may be truncated by omitting leading zero es so that the packet ends on the first possi- ble port boundary. the mseo pins behave the following way ("x" means "don?t care"): 0b11 followed by 0b00 indicates som 0b0x followed by 0b11 indicates eom 0b00 followed by 0b01 indicates evlp mseo is 0b00 at all other clocks during transmission of a message mseo is 0b11 at all clocks when idle. 9.3.3.4 clock and frame rate in single datarate mode (default), mdo and mseo should be sampled by an external tool on the rising edge of mcko. in double datarate mode , the mcko clock runs at half frequency, so mdo and mseo should be sampled on both edges of mck o. this is configured by the double dat- arate bit in the aux port control register. it is also possible to reduce the frequency of the aux port compared to the cpu clock by writing the axc:ls and axc:div bits. if ls=1, the div value selects the frame rate of the aux port: f aux = f cpu /(div+1) if ls=1 and div=0, f aux = f cpu /2. this can be combined with the single or dual datarate mode, as described above. in either case, the sampling edge will be as close to the middle of the mdo data fram e as possible. the duty cycle of the mcko clock will stay within the 40-60 duty cycle requiremen t of the nexus standard for all settings apart from div=2. 9.3.3.5 example figure 9-5 shows an example of transmission of a program trace indirect branch message. the tcode is fixed at 6 bits (=4 for ptib), followed by a fixed-length packet (evt-id = 2), and a variable-length packet (i-cnt = 63). i-cnt is stuffed with zeroes to fit the port boundary. finally, the variable packet u-addr (=5) is transmitted. since this leading zeroes of this packet can be truncated, it fits within a single frame.
115 32002f?03/2010 avr32 figure 9-5. example of a nexus message transmission with single and double datarate. 9.3.3.6 transmit queue and overruns messages from various sources are inserted in a transmit queue (txq), which stores a number of frames. this queue acts as a fifo which allows messages to be inserted more rapidly than they can be retrieved by the emulator. the queue holds 16 frames. if more messages are inserted than there is room for in the queue, information will be lost, and an ov errun situation occu rs. the txq will block any more messages from being inserted, and allow the queue to be emptied by the emulator before allowing any more messages to be inserted. the first message to be inserted after the overrun is cleared, is an error message, which informs the emulator that an overrun has occurred and which types of trace messages have been lost. after this, transmission continues as normal. alternatively, the user can configure the ocd to halt the cpu to prevent overruns. this can be done selectively for different message types, and is controlled by writing to the overrun control (ovc) bits in the dc register. if any of the ovc bits are set, watchpoint trace messages will usually not generate txq over- flow. however, triggering an program and data watchpoint on the same instruction may in some rare cases cause an overrun independently of the ovc settings, since a large amount of trace message data will be produced for th is instruction. 9.3.3.7 trace and reset all pending trace messages in the transmit queu e are flushed if: the ocd is reset by a system reset; the ocd is disabled; or an application reset is triggered by writing to the dc:res bit. thus, if the cpu is reset, but not the ocd, the program flow can be observed by program trace. however, if the debugger resets the system, the remaining messages in the queue are of no value, and expected to be flushed. note that if the ocd is disabl ed (by clearing dc:dbe or by a system reset), trace is suspended until dc:dbe is written to one. the dc:tm bits must be written simultaneously, and define which trace features should now be active. similarly, when an application reset is triggered by writing dc:res, the dc:tm bits are written simultaneously and define which trac e features should now be active. mcko (ddr=1) mcko (ddr=0) mseo[1..0] 1 1 0 0 0 1 1 1 mdo[5..0] 0 0 0 1 0 0 1 1 1 1 1 0 0 0 0 0 1 1 0 0 0 1 0 1 tcode = 4 evt-id = 2 i-cnt = 63 u-addr = 5 zero stuffing idle som normal evlp eom
116 32002f?03/2010 avr32 9.3.4 messages 9.3.4.1 error the error message indicates various errors that can occur during trace or debugging. table 9-21 lists the various errors that can be r eported, along with the associated ecode. if trace messages are lost because of insuffici ent space in the transmit queue, an error mes- sage is transmitted, followed by a synchronization message, as soon as space is available in the transmit queue. 9.3.5 registers 9.3.5.1 auxiliary port co ntrol register (axc) table 9-22 shows the description of the auxiliary port control register . this register allows greater flexibility in c ontrolling the operatio n of the aux port than specified by the nexus stan- table 9-20. error indirect branch message with sync direction: from target packet size (bits) packet name packet type description 5 ecode fixed error code. refer to table 9-21 . 6tcodefixedvalue = 8 table 9-21. error codes ecode description 0b00000 ownership trace overrun 0b00001 program trace overrun 0b00010 data trace overrun 0b00011 - 0b00101 reserved 0b00110 watchpoint overrun. 0b00111 program and/or data and/or ownership trace overrun. 0b01000 program trace and/or data and/or ow nership trace and/or watchpoint overrun. 0b01001 - 0b11111 reserved
117 32002f?03/2010 avr32 dard. this includes ena bling the aux port, and controlling the speed of the clock and data compared to the cpu clock. 9.4 breakpoints 9.4.1 overview the nexus recommended register map supports up to 8 universal breakpoints. however since the avr32uc hardware employs separate instruction and data memories, the ocd system must also separate program and data breakpoints. any breakpoint can also be programmed as table 9-22. aux port control register r/w bit number field na me init. val. description r 31:16 reserved 0 reserved these bits are reserved, and will always read as 0 r/w 15:14 axs 0 axs - auxiliary port select 0: aux port is mapped to pin configuration 0. 1: aux port is mapped to pin configuration 1. 2: aux port is mapped to pin configuration 2. 3: aux port is mapped to pin configuration 3. r 13 reserved 0 reserved this bit is reserved, and will always read as 0 r 12 reserved 0 reserved this bit is reserved, and will always read as 0. r/w 11 ls 0 ls - low speed 0:aux port runs at the same speed as the cpu 1:aux port runs at reduced speed compared to the cpu. r/w 10 ddr 0 ddr - double data rate setting this bit halves the mcko rate so that mdo data must be sampled on both edges of mcko. 1 = double data rate mode 0 = single datarate mode r/w 9 axo 0 axo - auxiliary port override 0: aux port is mapped to the pins dictated by axs. 1: aux port is overridden and mapped to pin configuration 1. r/w 8 axe 0 axe - auxiliary port enable 0: aux port is used for gpio 1: aux port is used for nexus operation. this bit does not need to be written in devices with dedicated aux pins r 7:4 reserved 0 reserved these bits are reserved, and will always read as 0 r/w 3:0 div 0 div - division factor if ls=1, the div value selects the frame rate of the aux port.
118 32002f?03/2010 avr32 a watchpoint. the watchpoint will trigger a watchpoint hit me ssage. the ocd system supports up to six program breakpoints modules and two data breakpoint modules. in addition to this, the data trace modules can also be used as data address watchpoints. the trace watchpoints result in a vendor defined trace watchpoint hit message. figure 9-6. breakpoint modules. program bp/wp data bp/wp cpu pc trace bp/wp data address data v alue data address
119 32002f?03/2010 avr32 figure 9-7. breakpoint unit overview. 9.4.2 breakpoint unit description the breakpoint unit consists of the units shown in figure 9-7. the pc breakpoint unit (pbu) handles the program counter breakpoints. the pbu can have up to 6 pc breakpoint modules that can match on a single pc. two modules can be combined to give a match on a range of pc values, thus up to three ranges can be defined. the pbu is configured with registers breakpoint / watchpoint control (bwc) and breakpoint / wa tchpoint address (bwa) 0a, 0b, 1a, 1b, 2a, and 2b. the data breakpoint unit handles data breakpoints. the data breakpoints can be configured with the bwc / bwa / bwd 3a and 3b registers. d ata b reakpoint u nit p c b reakpoint u nit pc breakpoint module 0a pc breakpoint module 0b pc breakpoint module 1a pc breakpoint module 1b pc breakpoint module 2a pc breakpoint module 2b data breakpoint module 3a data breakpoint module 3b 6 pc breakpoints 6 pc watchpoints 2 data breakpoints 2 data watchpoints w atchpoint m essage g enerator messages to transmit queue program trace unit data trace unit t rigger u nit 5 pc watchpoints 2 data watchpoints start/ stop start/ stop 2 range data watchpoints
120 32002f?03/2010 avr32 the watchpoint message generator (wmg) generates watchpoint messages for all breakpoint modules and data trace watchpoints. optionally, a breakpoint or watchpoint c an be signalled by a pulse on the evto pin. this requires dc:eos bits to be set to 1 and eoc in the corresponding breakpoint/watchpoint con- trol register must be written to one. 9.4.2.1 program breakpoints in order to enable a simple program breakpoint the breakpoint / watchpoint address (bwa) and breakpoint / watchpoint control (bwc) registers for that breakpoint must be updated. the bwa register must be written with the address of the instruction where the debugger wants to halt. the bwc must have the breakpoint / watchpoint enable (bwe) field set to breakpoint. program breakpoints break on the instruction poi nted to by bwa. the instruction will cause a debug exception and the debug mode link register (rar_dbg) and debug mode return sta- tus register (rsr_dbg) will point to the inst ruction that caused the debug exception. the development status register will also be updated to indi cate which breakpoint caused the exception. in ocd mode the debug tool can then feed the cpu with debug code to ascertain the state of the processor. in ocd mode the breakpoint modules are disabled. upon return from debug mode, the pc and sr will be restored from the rar_dbg and rsr_dbg and the instruction that caused the debug exception will be fetched again. if the pro- gram breakpoint has not been disabled in debug mode, the ignore first match (ifm) bit in the development control (dc) register must be written to one to avoid triggering another breakpoint on the first instruction after exiting debug m ode. the ifm bit prevents any program breakpoint operation on the first instruction after exiting debug mode. 9.4.2.2 watchpoints when enabled in the bwc, a watchpoint message is sent when the instruction address matches the address stored in bwa. if both a trace wa tchpoint and a watchpoint triggers at the same time, the trace watchpoint will be ignored and only a watchpoint hit message will be generated. note that program, data, and trace watchpoints are generated at different pipeline stages and will not be synchronized when the messages are generated. a program watchpoint on a load store instruction will hit be fore a data watchpoint on the same instruction. 9.4.2.3 data breakpoints data breakpoint modules listen on the data address and data value lines between the cpu and the data cache and can halt the cpu, or send a watchpoint message, if the address and / or value meets a stored compare value. unlike program breakpoints, data breakpoints halt on the next instruction after the load / store instruction that caused the breakpoint has completed. the bwa register must be written with the address of the data the debugger wants to halt on. 9.4.3 data breakpoint interface 9.4.3.1 data alignment the avr32 can read or write data in bytes, halfwords, or words. the same data location can be accessed through either operation, e.g. a byte location can be accessed as part of a double word. the data bus operations seen by the ocd system are always aligned, i.e. halfwords start on halfword boundaries, word ac cesses start on word boundaries, as illustrated in figure 9-8. if
121 32002f?03/2010 avr32 the data bus operation is a do uble word load / store, the br eakpoint module will see the word data value which corresponds to the address in bwa. one data breakpoint module can only compare 32 bits of data. the data to be matched can therefore not cross a word boundary if the data breakpoint is to match correctly. when the debugger wants to match on a byte or halfword, the bwd register must be written with the lsb aligned, and the bwc:bme bits must be set to mask the upper bits of the bwd register. for example, if the debugger wants to match against byte 1 in figure 9-8, the bwa must be set to the byte address of byte 1 and the bwd wr itten with the value to match on aligned to lsb. also the bwc:bme must be set to mask the 24 most significant bits of the bwd register (bme = 0xe). by default, the data breakpoint module will match on the data value regardless of the size of the access. the data bwc can also be set to match on a specific access size if the size bits are set. the debugger can for example, set the breakpoint module to match only on byte writes to byte 1 in figure 9-8. the bwd re gister must still be aligned corr ectly, and the byte mask must be set, but the data breakpoint will on ly trigger if a single byte is wr itten to byte 1 and not if, for example, a whole word is writ ten to byte 0, 1, 2, and 3. figure 9-8. memory access data alignment. 9.4.4 triggering trace a watchpoint from the program or data breakpoint modules can be used to start or stop program or data trace. this is done using a trigger unit. the trigger unit can be configured using the watchpoint trigger register. when the trigger unit is set to start trace upon a watchpoint, dc:tm will be set accordingly, and trace will then be enabled. if a data watchpoint enables data trace, the data event is not included in the data trace output, while an event which disables data trace is included in the data trace output. word byte 0 byte 3 byte 2 byte 1 half w ord 0 half w ord 1 0x8008 0x8004 0x8000 0 1 2 3 byte address word address double w ord byte 4 to 7 double w ord byte 0 to 3 0x800c 0x8010
122 32002f?03/2010 avr32 9.4.5 messages 9.4.5.1 watchpoint hit (wh) 9.4.5.2 trace watchpoint hit (twh) 9.4.6 registers 9.4.6.1 pc breakpoint/watchpoint address register s (bwa0a, bwa0, bwa1a, bwa1b, bwa2a, bwa2b) the 6 bwa registers contains one instruction ad dress each. the address can be used for a sin- gle breakpoint match or used as bitwise mask to create a range. table 9-23. watchpoint hit watchpoint message direction: from target packet size packet name packet type description 8wphitfixed xxxxxxx1 = watchpoint 0 matched xxxxxx1x = watchpoint 1 matched ... x1xxxxxx = watchpoint 6 matched 1xxxxxxx = watchpoint 7 matched 6 tcode fixed value = 15 table 9-24. trace watchpoint hit trace watchpoint message direction: from target packet size packet name packet type description 2wphitfixed x1 = watchpoint 0 matched 1x = watchpoint 1 matched 6 tcode fixed value = 56 table 9-25. pc bwanx register r/w bit number field na me init. val. description r/w 31:0 bwa 0 breakpoint/watchpoint address
123 32002f?03/2010 avr32 9.4.6.2 pc breakpoint/watchpoint control registers - (bwc0a, bwc0b, bwc1a, bwc1b, bwc2a, bwc2b) 9.4.6.3 data breakpoint / watchpoint address (bwa3a, bwa3b) 9.4.6.4 data breakpoint / watchpoint data (bwd3a, bwd3b) table 9-26. pc bwcnx register r/w bit number field name init. val. description rw 31:30 bwe 00 bwe - breakpoint / watchpoint enable 00 = disabled 01 = breakpoint enabled 10 = reserved 11 = watchpoint enabled r 29:26 reserved 0 reserved rw 25 ame 0 ame - address mask enable this bit is only present in bwcxa registers. 0 = disabled. 1 = enabled. bwaxb will be used to bitwise mask the pc compare according to this function: bp a: (pc & bwa_b) == (bwa_a & bwa_b) bp b: will never trigger r 24:15 reserved 0 reserved rw 14 eoc 0 eoc - evto control 0 = breakpoint/watchpoint st atus indication is not output on evto 1 = breakpoint/watchpoint status indication is output on evto r 13:0 reserved 0 reserved table 9-27. data breakpoint/watchpoint address (bwa3x) register r/w bit number field name init. val. description rw 31:0 bwa 0x00000000 address of data for breakpoint or watchpoint generation. table 9-28. data breakpoint/watchpoint data (bwd3x) register r/w bit number field name init. val. description rw 31:0 bwd 0x00000000 data value for breakpoint or watchpoint generation.
124 32002f?03/2010 avr32 9.4.6.5 data breakpoint / watchpoint control (bwc3a, bwc3b) table 9-29. data breakpoint / watchpoint control (bwc3x) r/w bit number field name init. val. description rw 31:30 bwe 00 bwe - breakpoint / watchpoint enable 00 = disabled 01 = breakpoint enabled 10 = reserved 11 = watchpoint enabled rw 29:28 brw 00 brw - breakpoint/watchpoint read/write select 00 = break on read access 01 = break on write access 10 = break on any access 11 = reserved r 27:24 reserved 00 reserved rw 23:20 bme 0x0 bme - breakpoint/watchpoint data mask 1xxx = mask bits 31:24 in bwd x1xx = mask bits 23:16 in bwd xx1x = mask bits 15:8 in bwd xxx1 = mask bits 7:0 in bwd r 19:18 reserved 00 reserved rw 17:16 bwo 000 bwo - breakpoint/watchpoint operand 1x = compare with bwa value x1 = compare with bwd value r 15 reserved 0 reserved rw 14 eoc 0 eoc - evto control 0 = breakpoint/watchpoint status indication not output on evto 1 = breakpoint/watchpoint status indication is output on evto r 13:12 reserved 0 reserved r/w 11:9 size 000 size - size bits to match 0xx = disregard access size (default) 100 = byte access 101 = halfword access 110 = word access 111 = reserved r/w 8:0 reserved 0 reserved
125 32002f?03/2010 avr32 9.4.6.6 watchpoint trigger 9.5 program trace 9.5.1 program trace overview the avr32 ocd system provides program trace support via the debug port. the program trace feature implements a program flow change model in which the program trace is synchronized at each program flow discontinuity. this occu rs at taken indirect branches and exceptions. a record of taken / not taken direct branches is included so that the complete program flow can be decoded. the development tool can then interpolate what transpires between each program trace mes- sage by correlating information from branch target messaging and static source or object code files. self-modifying code cannot be traced with the program flow change model because the source code is not static. the tm[2] bit in the development control register must be set to enable program trace. 9.5.1.1 branch message summary five types of branch messa ges can be generated: 1. program trace, indirect branch is transmitted on most subroutine calls, returns, inter- rupts, exceptions, and any situation where the target address of a branch cannot be determined from the source code. this message contains the instruction count to iden- tify the branch and the target pc to identify the branch target. 2. program trace synchronization is transmitted to indicate the current pc after starting trace or after trace synchronization is lost. table 9-30. wt, watchpoint trigger register r/w bit number field name init. val. description r/w 31:29 pts 000 pts - program trace start 000 = trigger disabled 001 = program watchpoint 0b 010 = program watchpoint 1a 011 = program watchpoint 1b 100 = program watchpoint 2a 101 = program watchpoint 2b 110 = data watchpoint 3a 111 = data watchpoint 3b r/w 28:26 pte 000 pte - program trace end 000 = trigger disabled 001 <-> 111 watchpoint selected as for pts r/w 25:23 dts 000 dts - data trace start 000 = trigger disabled 001 <-> 111 watchpoint selected as for pts r/w 22:20 dte 000 dte - data trace end 000 = trigger disabled 001 <-> 111 watchpoint selected as for pts r 19:0 reserved - reserved
126 32002f?03/2010 avr32 3. program trace, indirect branch messages with sync contain both instruction count and pc, and are transmitted instead of a program trace synchronization message if a syn- chronization condition occurs and the curr ent instruction is a taken direct/indirect branch. 4. program trace, resource full messages is transmitted when an internal buffer over- flows. icnt is transmitted whenev er it overflows with this message. 5. program trace correlation. this message is transmitted to synchonize the program trace with an event. sent when trace is disabled, debug mode is entered or sleep mode is entered. the nexus standard also specifies program trac e correction messages to correct for specula- tively transmitted trace messages, but these are not implemented in the avr32, since program trace messages are only transmitted for actually executed instructions. similarly, the nexus- specified cancel packet of synchronized branch messages is not implemented in avr32. entry into debug mode will generate an program trace correlat ion message, while no trace mes- sages are generated while executing in d ebug mode. a program trace synchronization message is transmitted when debug mode is exited. 9.5.2 branch message packets the program trace messages contain packets wh ich identify the address of the taken branch, the target of the branch, and the current program counter value. these packets are discussed below. 9.5.2.1 instruction count packet in several of the program trace messages, an instruction count (i-cnt) packet is included, to identify the number of sequentially executed instruction units since the last program trace mes- sage. in avr32, this figure refers to bytes, i.e. compact instructions count two bytes and extended instructions are four bytes. the following rules apply to instruction counts: a taken indirect branch which generates a trace message is not included in the instruction count. an indirect branch which is not taken is included in the instruction count. speculatively fetched instructions are not counted until they are actually executed. the instruction counter is reset every time a program trace message is generated. 9.5.2.2 compressed program counter packets to save bandwidth, the nexus messages employ compressed versions of the program counter address. these include: u-addr = stripleadingzeros (previous sent addr xor uncompressed address from pipeline). f-addr = full target address for a taken branch. leading zeroes may be truncated. 9.5.3 special cases 9.5.3.1 debug mode when entering debug mode, a ptc message is generated with evcode = 0. when exiting debug mode, a ptsy message is generated. if the instruction also generates a branch message, the branch message with sync (i.e. ptdbs or ptibs) is generated instead of
127 32002f?03/2010 avr32 ptsy. in this case, the address of the instruction which generated the branch message can not be explicitly reconstructed from the trace log, but the debugger will normally know which address was returned to when debug mode was exited. if a breakpoint occurs on the first instruct ion after exiting debug mode, a ptc message with evcode = 0 is generated. 9.5.4 messages 9.5.4.1 program trace, direct branch this message is output by the target processor whenever there is a change of program flow caused by a conditional or unconditional branch. the instruction count (i-cnt) is included to identify the branch address. the following avr32 instructions can cause a direct branch: 9.5.4.2 program trace, direct branch with target address this message is transmitted instead of the direct branch message when sqa enhanced pro- gram trace is enabled by writing dc:sqa to one. this simplifies real-time pc reconstruction in the emulator for real-time code coverage and performance analysis purposes. 9.5.4.3 program trace, indirect branch an indirect branch is output by the target processor whenever there is a change of program flow caused by a subroutine call, return instruction, interrupt, or exception. table 9-31. direct branch instructions mnemonic description br{cond3} compact branch if condition satisfied. br{cond4} extended rjmp compact branch if condition satisfied. table 9-32. direct branch message without sync direct branch message direction: from target packet size (bits) packet name packet type description 8 i-cnt variable number of bytes executed since the last taken branch. 6 tcode fixed value = 3 table 9-33. direct branch message with target address direct branch message with sync direction: from target packet size (bits) packet name packet type description 32 u-addr variable the unique portion of the branch target address for a taken indirect branch or exception. mo st significant bits that have a value of 0 are truncated. 8 i-cnt variable number of bytes executed since the last taken branch. 6 tcode fixed value = 57
128 32002f?03/2010 avr32 messages for taken indirect branches and exc eptions include how many sequential bytes were executed since the last taken branch or exception, and the unique portion of the branch target address or exception vector address. the unique portion of the branch is found by doing an exclusively or on the branch target and the last sent uaddr / faddr. additionally, the cause of the indirect branch is identified through an event id packet. oper ations causing indirect branches and their corresponding evt-id are shown below. note that subrotine returns are often accomplished by a mov pc, lr , popm or ldm instruction with pc included in the argument list. this generates an evt-id of 0 instead of 1.. 9.5.4.4 program trace synchronization this message is output by the ptu when any of the following conditions occurs: 1. upon exit from reset. this is required to allow the number of instruction units executed packet in a subsequent program trace message to be correctly interpreted by the tool. 2. when program trace is enabled during normal execution of the embedded processor. 3. upon exit from a power-down state. this is required to allow the number of instruction units executed packet in a subsequent program trace message to be correctly inter- preted by the tool. 4. upon exiting from debug mode. 5. an overrun condition had previously occurred in which one or more branch trace occur- rences were discarded by the target processo r?s debug logic.to inform the tool that an overrun condition occurred, the target outputs an error message (tcode = 8) with an table 9-34. operations causing indirect branch messages description operation evt-id exception entry exception, interrupts (0 to 3), nmi, entry to debug mode 3 subroutine call acall, icall, mcall, jcall, scall, rcall instruction 2 branch via register contents any mov (except mov pc, lr) or load (except popm/ldm) with pc as destination. any arithmetic instruction with pc as destination. 1 return ret{cond4}, rete, rets, retj, (m ov pc, lr), popm/ldm loading pc 0 table 9-35. indirect branch message without sync indirect branch message direction: from target packet size (bits) packet name packet type description 32 u-addr variable the unique portion of the branch target address for a taken indirect branch or exception. mo st significant bits that have a value of 0 are truncated. 8 i-cnt variable number of bytes executed since the last taken branch. 2evt-idfixed cause of indirect branch: 3: exception entry 2: call 1: branch via register contents 0: return 6 tcode fixed value = 4
129 32002f?03/2010 avr32 ecode value of 00001 or 00111 immediately prior to the program trace synchroniza- tion message. 6. a debug control register field specifies that evti pin action is to generate program trace synchronization, and the event-in (evti ) pin has been asserted. 7. upon overflow of the sequential instruction unit counter. 8. after 256 branch messages without sync. 9.5.4.5 program trace, direct branch with sync if a program trace synchronization message occurs on an instruction which transmits a direct branch message, the direct branch with sync me ssage is transmitted instead of the program trace synchronization message. the direct branch with sync message contains the instruction count referring to the taken branch, as well as the complete pc value of the branch target. the format for direct branch messages with sync is shown below. the avr32 ocd system never issues speculative bran ch messages and there is therefore no cancel packet. 9.5.4.6 program trace, indirect branch with sync if a program trace synchronization message occurs on an instruction which transmits an indi- rect branch message, the indirect branch with sync message is transmitted instead of the program trace synchronization message. the indi rect branch with sync message contains the instruction count referring to the taken branch, as well as the complete pc value of the branch target. table 9-36. program trace synchronization message program trace sync message direction: from target packet size (bits) packet name packet type description 32 pc variable the full current instruction addres s. most significant bits that have a value of 0 are truncated. 8 i-cnt variable number of bytes executed since the last taken branch. 6tcodefixedvalue = 9 table 9-37. direct branch message with sync direct branch message with sync direction: from target packet size (bits) packet name packet type description 32 f-addr variable the full target address for a taken direct branch. most significant bits that have a value of 0 are truncated. 8 i-cnt variable number of bytes executed since the last taken branch. 6 tcode fixed value = 11
130 32002f?03/2010 avr32 the format for indirect branch messages with sync is shown below. the avr32 ocd system never issues speculative bran ch messages and there is therefore no cancel packet. 9.5.4.7 program trace, resource full this message is output whenever an internal re source (sequential instruction counter) has reached its maximum value. to avoid losing in formation when this resource becomes full, the resource full message is transmitted. the information from this message is added with infor- mation from subsequent messages to interpret the fu ll picture of what has transpired. multiple resource full messages can occur before the arrival of the message that the information belongs with. table 9-38. indirect branch message with sync indirect branch message with sync direction: from target packet size (bits) packet name packet type description 32 f-addr variable the full target address for a taken direct branch. most significant bits that have a value of 0 may be truncated. 8 i-cnt variable number of bytes executed since the last taken branch. 2 evt-id fixed cause of indirect branch: 3: exception entry 2: call 1: branch via register contents 0: return 6 tcode fixed value = 12 table 9-39. resource full message program trace, resource full direction: from target packet size (bits) packet name packet type description 8 rdata variable number of bytes executed since the last taken branch. 4 rcode fixed resource code. this code indica tes which internal resource has reached its maximum value. refer to table 9-40 for details. 6 tcode fixed value = 27 table 9-40. resource code (rcode) description resourc e code resource data packet value 0b0000 program trace - sequential instruction counter number of instruction units executed since the last taken branch. 0b0001 - 0b1111 reserved
131 32002f?03/2010 avr32 9.5.4.8 program trace correlation program trace correlation messages are used to correlate events to the program flow that may not be associated with the instruction stream (e.g. data trace messages). the occurrence of an event listed in table 9-41 will caus e this message to be transmitted. 9.5.5 registers program trace is enabled using the tm field in the development control register. 9.6 data trace 9.6.1 overview the avr32 ocd system provides data trace via the aux port. the cpu data memory accesses can be monitored real-time using the nexus clas s 2+ compliant data trace unit. both reads and writes can be traced. data trace information is transmitted through data trace messages, which can be of read or write type, with or without sync. the messages contain information about the data address and value which triggered the trace. data addresses can be complete (with sync), or compressed relative to the previous transmitted message (without sync). the value contains the data value read or written from the data cache, and is of the same width as the access size (byte, halfword, word, or doubleword). the tm[1] bit in the development control register must be set to enable data trace. it is also possible to trigger data trace using watchpoints. in this case, tm[1] will be set or cleared automatically. table 9-41. program trace correlation message program trace correlation direction: from target packet size (bits) packet name packet type description 8 i-cnt variable number of instruction units executed since the last taken branch. 4 evcode fixed event code. refer to table 9-42. 6 tcode fixed value = 33 table 9-42. event code (evcode) description event code (evcode) event description 0b0000 entry into debug mode 0b0001 entry into low power mode 0b0010 - 0b0011 reserved 0b0100 program trace disabled 0b0101 - 0b1111 reserved
132 32002f?03/2010 avr32 9.6.2 using data trace channels as watchpoints data trace is enabled for address ranges (trace channels) specified by pairs of data trace start and end address registers (dt sa/dtea). each data access with in that boundary will generate an action as specified by the corresponding bits in the data trace control register (dtc). the avr32 ocd system currently supports two data trace channels. while each channel can be used to trigger data tr ace messages, it is al so possible to trigger watchpoint messages, providing flexibility wh en using the ocd system. watchpoints can be ranged, i.e. trigger on all accesses between dtsa through dtea, or trigger on a single location, if dtsa and dtea are written to the same value. writing tnwp to one enables a watchpoint on accesses for data trace channel n. the watch- point message is sent as a vendor defined trace watchpoint message. it is possible to enable both trace and watchpoint on the same channel, but typically, only one of the options will be used. 9.6.3 messages the trace watchpoint hit message is described in section 9.4.5.2 on page 122 . 9.6.3.1 data trace, data write (dtdw) this message is output by the target processor when it detects a memory write that matches the ocd system?s data trace attributes. 9.6.3.2 data trace, data write with sync (dtdws) this message is an alternative to the data trace, data write message. it is output instead of a data trace, data write message whenever a memory write occurs that matches the debug logic?s data trace attributes, and when one of the following conditions has occurred: 1. the processor has exited from reset. this synchronization message is required to allow the unique portion of the data write address of following data trace, data write mes- sages to be correctly interpreted by the tool. 2. when data trace is enabled during normal execution of the embedded processor. table 9-43. data trace, data write message data trace, data write message direction: from target packet size packet name packet type description 8 / 16 / 32 data variable the data value written. the size will vary depending on the load / store instruction being traced. 32 u-addr variable the unique portion of the data write address, which is relative to the previous data trace message (read or write). 2dszfixed data size: 00 = 8 bits 01 = 16 bits 10 = 32 bits 6tcodefixedvalue=5
133 32002f?03/2010 avr32 3. upon exit from a power-down state. this synchronization message is required to allow the unique portion of the data write address of following data trace, data write mes- sages to be correctly interpreted by the tool. 4. the event-in pin has been asserted and a debug control register field specifies that evti pin action is to generate data trace synchronization. 5. an overrun condition had previously occurred in which one or more data trace occur- rences were discarded by the target processor?s debug logic. to inform the tool that an overrun condition occurred,the target outputs an error message (tcode = 8) with an ecode value of 00010 or 00111 immediately prior to the data trace, data write with sync message. 6. the data trace message counter has expired indicating that at most 256 without-sync versions of data trace messages have been sent since the last with-sync version. 7. a data write is detected following the processor exiting from debug mode. 9.6.3.3 data trace, data read (dtdr) this message is output by the target processor when it detects a memory read that matches the ocd system?s data trace attributes. table 9-44. data trace, data wr ite with sync message data trace, data write with sync message direction: from target packet size packet name packet type description 8 / 16 / 32 data variable the data value written. the size will vary depending on the load / store instruction being traced. 32 f-addr variable the full address of the memory loca tion written. most significant bits that have a value of 0 are truncated. 2dszfixed data size: 00 = 8 bits 01 = 16 bits 10 = 32 bits 6tcodefixedvalue=13 table 9-45. data trace, data read message data trace, data read me ssage direction: from target packet size packet name packet type description 8 / 16 / 32 data variable the data value read. the size will vary depending on the load / store instruction being traced. 32 u-addr variable the unique portion of the data read address, which is relative to the previous data trace message (read or write). 2dszfixed data size: 00 = 8 bits 01 = 16 bits 10 = 32 bits 6tcodefixedvalue=6
134 32002f?03/2010 avr32 9.6.3.4 data trace, data read with sync (dtdrs) this message is an alternative to the data trace, data read message. it is output instead of a data trace, data read message whenever a memory read occurs that matches the debug logic?s data trace attributes, and when one of the following conditions has occurred: the processor has exited from reset. this syn chronization message is required to allow the unique portion of the data write address of following data trace, data read messages to be cor- rectly interpreted by the tool. when enabling data trace is during normal execution of the embedded processor. upon exit from a power-down state. this sync hronization message is required to allow the unique portion of the data write address of following data trace, data read messages to be cor- rectly interpreted by the tool. the event-in pin has been asserted and a debug control register field specifies that evti pin action is to generate data trace synchronization. an overrun condition had previously occurred in which one or more data trace occurrences were discarded by the target processor?s debug logic. to inform the tool that an overrun condition occurred, the target outputs an error message (tcode = 8) with an ecode value of 00010 or 00111 immediately prior to the data trace, data read with sync message. the periodic data trace message counter has ex pired indicating that 255 without-sync versions of data trace messages have been sent since the last with-sync version. a data read is detected following the processor exiting from debug mode. table 9-46. data trace, data re ad with sync message data trace, data read with sync message direction: from target packet size packet name packet type description 8 / 16 / 32 data variable the data value read. the size will vary depending on the load / store instruction being traced. 32 f-addr variable the full address of the memory location written. most significant bits that have a value of 0 are truncated. 2dszfixed data size: 00 = 8 bits 01 = 16 bits 10 = 32 bits 6tcodefixedvalue=14
135 32002f?03/2010 avr32 9.6.3.5 data trace, read-modify-write (dtrmw) this message is generated when a read-modify-write (rmw) instruction is generated with a target address within an active data trace window. these instructions have the format "memc/s/t imm, bp", and can clear, set, or toggle a specified bit in memory. 9.6.3.6 data trace, read-modify-write with sync (dtrmws) this message is output instead of dtrmw under the same conditions as shown for dtdws. table 9-47. data trace, read-modify-write message data trace, read-modify-write message direction: from target packet size packet name packet type description 32 u-addr variable the unique portion of the data write address, which is relative to the previous data trace message (read or write). 5 bit variable bit argument of the rmw instruction. 2 type fixed bit operation: 00 = reserved 01 = clear 10 = set 11 = toggle 6tcodefixedvalue=58 table 9-48. data trace, read-modify-write with sync message data trace, read-modify-write with sync message direction: from target packet size packet name packet type description 32 f-addr variable the full address of the memory location written. most significant bits that have a value of 0 are truncated. 5 bit variable bit argument of the rmw instruction. 2 type fixed bit operation: 00 = reserved 01 = clear 10 = set 11 = toggle 6tcodefixedvalue=59
136 32002f?03/2010 avr32 9.6.4 registers 9.6.4.1 data trace control register (dtc) this register controls actions taken on data accesses within all data trace channels. 9.6.4.2 data trace start/end address register (dtsa/dtea) dtsan and dtean define the inclusive data ac cess range [dtsan : dtean] for trace channel n. each trace channel 0 and 1 has its own dtsa/ dtea register pair. if dtsa=dtea, the trace channel will match on accesses to a single lo cation. if dtsa>dtea, no match will occur for the trace channel. dtsa0, dtsa1 dtea0, dtea1 9.7 ownership trace 9.7.1 functional description the avr32 ocd system implements ownership trace in compliance with the nexus standard. ownership trace provides a macr oscopic view, such as task fl ow reconstruction, when debug- ging software written in a high level (or objec t oriented) language. it offers the highest level of abstraction for tracking operating system software execution. this is especially useful when the developer is not interested in debugging at lower levels. ownership trace is especially important for embedded processors with a memory management unit, in which all processes can use the same virtual program and data spaces. ownership trace table 9-49. data trace control register r/w bit number field na me init. val. description r/w 31:30 rwt0 0 rwt0 - read/write trace channel 0 00 = no trace enabled x1 = enable data read trace 1x = enable data write trace r/w 29:28 rwt1 0 rwt1 - read/write trace channel 1 00 = no trace enabled x1 = enable data read trace 1x = enable data write trace r 27:2 reserved 0 r/w 1 t1wp 0 t1wp - trace channel 1 watchpoint r/w 0 t0wp 0 t0wp - trace channel 0 watchpoint table 9-50. data trace start address register r/w bit number field name init. val. description r/w 31:0 dtsa 0 dtsa - start address for trace visibility table 9-51. data trace end address register r/w bit number field name init. val. description r/w 31:0 dtea 0 dtea - end address for trace visibility
137 32002f?03/2010 avr32 offers development tools a mechanism to decipher which set of symbolics and sources are associated for lower levels of visibility and debugging. ownership trace information is transmitted ou t the aux using an ownership trace message. otm facilitates ownership trace by providing visibility of which process id or operating system task is activated. an ownership trace messa ge is transmitted to indicate when a new pro- cess/task is activated, allowing development tools to trace ownership flow. additionally, an ownership trace message is also transmitted periodically during runtime at a minimum fre- quency of every 256 program trace or data trace messages. in the avr32, this feature is supported thr ough an ownership trace register, which automati- cally produces an ownership trace message w hen written to. the rtos scheduler routine writes the new process id to this register during process switching using the mtdr instruction. the tm[0] bit in the development control register must be set to enable ownership trace. 9.7.2 messages 9.7.2.1 ownership trace (ot) the ownership trace message is sent: when the ownership trace process id (pid) register is written. when program trace with sync message is generated due to overflow in the periodic message counter. when a data trace with sync message is generate d due to overflow in the periodic message counter. after a transmit queue overrun if the cpu has written to pid when the queue was full. if there is no room in the transmit queue for the message, and the cpu is not halted to prevent overruns, an error message is produced. 9.7.3 registers 9.7.3.1 ownership trace process id (pid) the cpu should write the current process id valu e to this register, whenever the rtos per- forms a process switch. this will automatically create an ownership trace message to be transmitted to the tool. this register can be written from any privileged cpu mode. table 9-52. ownership trace message ownership trace message direction: from target packet size packet name packet type description 32 process fixed task / process id. 6tcodefixedvalue = 2
138 32002f?03/2010 avr32 the tool can read and write this register, although it is recommended that only the cpu writes this register. 9.8 memory service unit the memory service unit (msu) provides access to complex memory operations, such as crc checking and nanotrace. the msu is accessed by sab registers, but these are not mapped into the ocd register space, and needs to be accessed with memory_word_access or memory_service_access jtag commands. in addition the msu registers are mapped in the system register space and are available tothe cpu. refer to section 2.5 ?system registers? on page 11 for details. 9.8.1 crc the msu can calculate a cyclic redundancy check (crc) value for a memory area. the algo- rithm used is the industry standard crc32 algorithm using the generator polynomial 0xedb88320. 9.8.1.1 starting crc calculation to calculate crc for a memory range, you need to write the start address into the addrhi and addrlo registers, and the size of the memory range into the length register. both the start address and the length must be word aligned. the initial value used for the crc calculation must be written to the data register. this value will usually be 0xffffffff , but can be e.g. the result of a previous crc calcul ation if generat- ing a common crc of separate memory blocks. once completed, the calculated crc value can be read out of the data register. the read value must be inverted to match standard crc32 implementations, or kept non-inverted if used as starting point for subsequent crc calculations. if the device has enabled protection features, e.g. the protection fuse has been set on devices with onboard flash memory, it is only possible to calculate crc on a predefined memory area. in most cases this area will be the entire onboard flash memory. the addrhi, addrlo, length, and data registers will be forced to predefined values once the crc operation is started, and user-written values are ignored. this allows the user to verify the contents of a pro- tected device, while denying malicious users the option of analyzing the memory contents through selective crc calculations. the actual test is started by writing op_crc to the ctrl register. a running crc operation can be cancelled by writ ing op_idle to ctrl. table 9-53. ownership trace process id (pid) r/w bit number field na me init. val. description rw 31:0 process 0 process - process id the unique process id number of the currently running process.
139 32002f?03/2010 avr32 9.8.1.2 interpreting the results the user should monitor the result register. the possible values are: 9.8.2 nanotrace the msu redirect ocd trace output from the normal trace output port to memory. this feature is called nanotrace, and enables trace functionality with low cost debuggers, or even trace sup- port in self hosted debuggers. 9.8.2.1 starting nanotrace the memory range to write the trace data to is specified by writing the start address into the addrhi and addrlo registers, and the size of the memory range into the length register. in addition, the tail register may need to be updated, see below for details. both the start address and the length must be word aligned. the msu starts expecting trace data when op_nan otrace is written to the ctrl register. the ocd system must be separately configured to actually produce trace data. the ntbc field of ctrl controls how the memory service behaves when the trace buffer is full. 9.8.2.2 controlling buffer overflow the trace buffer as specified by the initial addrhi, addrlo an d length registers works as a circular buffer. the addrlo register is used by the msu as the insert or head pointer, and the tail register is used by the debugger as the extract or tail pointer. addrhi is used together with both addrlo and tail to ge nerate complete sab addresses. while writing trace data to memory, the ad drlo and length registers are continuously updated with the current address being written and bytes remaining until the end of the buffer. when length reaches zero, the original contents of addrlo and length are restored, and trace data are again written from the beginning of the buffer. the trace buffer is considered to be full when the addrlo regist er reaches the same value as tail. when starting trace, the tail register should be written to the same value as addrlo, meaning that the entire buffer can be written before addrlo matches tail. during tracing, a debugger may read out trace data from the buffer area between addrlo and tail, and then update tail. this will release space in the buffe r, and can potentially allow continuos tracing if the trace buffer can be read out faster than trace data is generated. when the buffer does fill up, the behavior of the ms u depends on the setting of the ntbc field: over: the unit keeps tracing, overwriting old trace data. the wrap field in the status register is set to indicate that trace data are lost. the ocd system is asked to generate a synchronization message as soon as possible. the wrap field must be manually cleared by writing it to zero. table 9-54. crc results result description not_impl the crc feature is not implemented in this device. canceled the crc operation was canceled by writ ing a value different from op_crc to ctrl. busy the crc operation is running. done the crc operation has completed. bus_err part of the specified memory could not be read or written. the offending address can be read out of addrhi and addrlo.
140 32002f?03/2010 avr32 disable: the msu leaves the nanotrace mode, and goes to idle mode. the ocd system will continue as before, but trace data will go to the trace output port if enabled. break_stop: the msu will ask the ocd system to en ter debug mode, so no more trace data is generated. there will be a few more trace messages that do not fit in the buffer, so the cpu is forced to stop until the debugger clears room in the trace buffer. this ensures that no trace data is lost, but this also means that this mode will deadlock self hosted debuggers, as the cpu is stalled and can never release room in the trace buffer! break_flush: the msu will ask the ocd system to ent er debug mode, so no more trace data is generated. there will be a few more trac e messages that do not fit in the buffer, but the msu will flush these and allow the cpu to en ter ocd mode. this mean s that the last few messages will be lost! when restarting nanotrace after entering debug mode using one of the break modes, the tail register must be updated in order to tell the msu that there is free space in the trace buffer. it is perfectly valid to update tail to the value it already contains - this is interpreted as making the entire buffer available. after this, the cpu can be restarted by issuing a retd instruction through the ocd system. if ntbc is set to break_flush the fi rst new trace message will be a synchronization message. 9.8.2.3 interpreting the results the debugger should monitor the result register. the possible values are: table 9-55. nanotrace results result description not_impl the nanotrace feature is not implemented in this device. canceled the nanotrace operation was canceled by writing a value different from op_nanotrace to ctrl. busy the nanotrace operation is running. done the nanotrace operation has completed. this can only happen when the ntbc field is written to disable. bus_err part of the specified memory could not be written to. the offending address can be read out of addrhi and addrlo.
141 32002f?03/2010 avr32 9.8.3 msu register summary table 9-56. msu register summary offset register name access reset state 0 address register, high part addrhi read/write - 1 address register, low part addrlo read/write - 2 length register length read/write - 3 control register ctrl read/write 0x0 4 status register status read-only 0x0 5 data register data read/write 0x0 6 tail address register tail read/write -
142 32002f?03/2010 avr32 9.8.3.1 address register, high part name: addrhi access type: read/write address offset: 0 addrhi: address high part bits 35:32 of full sab address 31 30 29 28 27 26 25 24 ???????? 23 22 21 20 19 18 17 16 ???????? 15 14 13 12 11 10 9 8 ???????? 76543210 ? ? ? ? addrhi
143 32002f?03/2010 avr32 9.8.3.2 address register, low part name: addrlo access type: read/write address offset: 1 addrlo: address low part bits 31-2 of full sab address. bits 1:0 always zero. 31 30 29 28 27 26 25 24 addrlo 23 22 21 20 19 18 17 16 addrlo 15 14 13 12 11 10 9 8 addrlo 76543210 addrlo 0 0
144 32002f?03/2010 avr32 9.8.3.3 length register name: length access type: read/write address offset: 2 length: length value bits 1:0 always zero. 31 30 29 28 27 26 25 24 length 23 22 21 20 19 18 17 16 length 15 14 13 12 11 10 9 8 length 76543210 length 0 0
145 32002f?03/2010 avr32 9.8.3.4 control register name: ctrl access type: read/write address offset: 3 op: requested operation: ntbc: nanotrace buffer control what to do when trace buffer is full: 31 30 29 28 27 26 25 24 ???????? 23 22 21 20 19 18 17 16 ???????? 15 14 13 12 11 10 9 8 ???????? 76543210 ?? ntbc op table 9-57. op field of control register op name description 0 none no operation, or cancel current operation 1 crc calculate crc of memory area 2 ntrace write trace data from debug system to memory others n/a reserved table 9-58. ntbc field of control register op name description 0 over overwrite old buffer contents 1 disable disable nanotrace 2 break_stop make the cpu enter debug mode, but stop cpu unt il place has been freed for the last few trace frames. note: this may deadlock self-hosted debuggers! 3 break_flush make the cpu enter debug mo de, and flush the la st few trace frames that don?t fit in the buffer.
146 32002f?03/2010 avr32 9.8.3.5 status register name: status access type: read/write address offset: 4 result: result of current or last operation wrap the nanotrace write buffer address has wrapped back to the start address. 31 30 29 28 27 26 25 24 ???????? 23 22 21 20 19 18 17 16 ???????? 15 14 13 12 11 10 9 8 ???????? 76543210 ? ? ? ? wrap result table 9-59. result field of status register op name description 0 done the previous operation finished successfully 1 busy some operation is currently active 2 not_impl the requested oper ation is not implemented 3 bus_err unable to access part of the requested memory area 4 failed the requested operation failed 5 locked the requested operation cannot be perform ed because chip security features are enabled 6 canceled the previous operation was canceled by the user others n/a reserved
147 32002f?03/2010 avr32 9.8.3.6 data register name: data access type: read/write address offset: 5 data: generic data register 31 30 29 28 27 26 25 24 data 23 22 21 20 19 18 17 16 data 15 14 13 12 11 10 9 8 data 76543210 data
148 32002f?03/2010 avr32 9.8.3.7 tail address register name: tail access type: read/write address offset: 7 tail: tail address register for nanotrace buffer. bits 1:0 always zero. 31 30 29 28 27 26 25 24 tail 23 22 21 20 19 18 17 16 tail 15 14 13 12 11 10 9 8 tail 76543210 tail 0 0
149 32002f?03/2010 avr32 9.9 ocd message summary table 9-62 shows the messages which can be tr ansmitted by the target on the aux port. ocd registers can be written by the tool using the jtag mechanism described in ?debug port? on page 109 . table 9-60. message summary tcode message public / vendor defined page 0 debug status (debs) public page 100 1 reserved 2 ownership trace (ot) public page 137 3 program trace, direct branch (ptdb) public page 127 4 program trace, indirect branch (ptib) public page 127 5 data trace, data write (dtdw) public page 132 6 data trace, data read (dtdr) public page 133 7 reserved 8 error (error) public page 116 9 program trace synchronization (ptsy) public page 128 10 reserved 11 program trace, direct branch with sync (ptdbs) public page 129 12 program trace, indirect branch with sync (ptibs) public page 129 13 data trace, data write with sync (dtdws) public page 132 14 data trace, data read with sync (dtdrs) public page 134 15 watchpoint hit (wh) public page 122 16?26 reserved 27 program trace resource full (ptrf) public page 130 28?32 reserved 33 program trace correlation (ptc) public page 131 34?55 reserved 56 trace watchpoint hit (twh) vendor page 122 57 direct branch with target address (dbta) vendor page 127 58 data trace, read-modify-write (dtrmw) vendor page 135 59 data trace, read-modify-write with sync (dtrmws) vendor page 135 60-62 reserved vendor 63 (0x3f) vendor defined extension message reserved vendor
150 32002f?03/2010 avr32 table 9-63 shows the format of the transmitted messages. packets shown in bold are variable length, the others are fixed length. all variable length packets can be truncated by omitting lead- ing zeroes, but will always end on a port boundary. table 9-61. message formats nexus message message format tcode [5:0] packet 1 packet 2 packet 3 debug status 0 status[31:0] ownership trace 2 process [31:0] - - error 8 ecode[4:0] - - program trace, direct branch 3 i-cnt[7:0] -- program trace, direct branch with target address 57 i-cnt[7:0] u-addr[31:0] - program trace, indirect branch 4 evt-id[1:0] i-cnt[7:0] u-addr[31:0] program trace synchronization 9 i-cnt[7:0] pc[31:0] - program trace, direct branch with sync 11 i-cnt[7:0] f-addr[31:0] - program trace, indirect branch with sync 12 evt-id[1:0] i-cnt[7:0] f-addr[31:0] program trace resource full 27 rcode[3:0] rdata[7:0] program trace correlation 33 evcode[3:0] i-cnt[7:0] data trace, data write 5 dsz[1:0] u-addr[31:0] data[31:0] data trace, data read 6 dsz[1:0] u-addr[31:0] data[31:0] data trace, read- modify-write 58 type[1:0] bit[4:0] u_addr[31:0] data trace, data write with sync 13 dsz[1:0] f-addr[31:0] data[31:0] data trace, data read with sync 14 dsz[1:0] f-addr[31:0] data[31:0] data trace, read- modify-write with sync 59 type[1:0] bit[4:0] f_addr[31:0] watchpoint hit 15 wphit[7:0] - - trace watchpoint hit 56 wphit[1:0] - -
151 32002f?03/2010 avr32 9.10 ocd message summary table 9-62 shows the messages which can be tr ansmitted by the target on the aux port. ocd registers can be written by the tool using the jtag mechanism described in ?debug port? on page 109 . table 9-62. message summary tcode message public / vendor defined page 0 debug status (debs) public page 100 1 reserved 2 ownership trace (ot) public page 137 3 program trace, direct branch (ptdb) public page 127 4 program trace, indirect branch (ptib) public page 127 5 data trace, data write (dtdw) public page 132 6 data trace, data read (dtdr) public page 133 7 reserved 8 error (error) public page 116 9 program trace synchronization (ptsy) public page 128 10 reserved 11 program trace, direct branch with sync (ptdbs) public page 129 12 program trace, indirect branch with sync (ptibs) public page 129 13 data trace, data write with sync (dtdws) public page 132 14 data trace, data read with sync (dtdrs) public page 134 15 watchpoint hit (wh) public page 122 16?26 reserved 27 program trace resource full (ptrf) public page 130 28?32 reserved 33 program trace correlation (ptc) public page 131 34?55 reserved 56 trace watchpoint hit (twh) vendor page 122 57 direct branch with target address (dbta) vendor page 127 58 data trace, read-modify-write (dtrmw) vendor page 135 59 data trace, read-modify-write with sync (dtrmws) vendor page 135 60-62 reserved vendor 63 (0x3f) vendor defined extension message reserved vendor
152 32002f?03/2010 avr32 table 9-63 shows the format of the transmitted messages. packets shown in bold are variable length, the others are fixed length. all variable length packets can be truncated by omitting lead- ing zeroes, but will always end on a port boundary. table 9-63. message formats nexus message message format tcode [5:0] packet 1 packet 2 packet 3 debug status 0 status[31:0] ownership trace 2 process [31:0] - - error 8 ecode[4:0] - - program trace, direct branch 3 i-cnt[7:0] -- program trace, direct branch with target address 57 i-cnt[7:0] u-addr[31:0] - program trace, indirect branch 4 evt-id[1:0] i-cnt[7:0] u-addr[31:0] program trace synchronization 9 i-cnt[7:0] pc[31:0] - program trace, direct branch with sync 11 i-cnt[7:0] f-addr[31:0] - program trace, indirect branch with sync 12 evt-id[1:0] i-cnt[7:0] f-addr[31:0] program trace resource full 27 rcode[3:0] rdata[7:0] program trace correlation 33 evcode[3:0] i-cnt[7:0] data trace, data write 5 dsz[1:0] u-addr[31:0] data[31:0] data trace, data read 6 dsz[1:0] u-addr[31:0] data[31:0] data trace, read- modify-write 58 type[1:0] bit[4:0] u_addr[31:0] data trace, data write with sync 13 dsz[1:0] f-addr[31:0] data[31:0] data trace, data read with sync 14 dsz[1:0] f-addr[31:0] data[31:0] data trace, read- modify-write with sync 59 type[1:0] bit[4:0] f_addr[31:0] watchpoint hit 15 wphit[7:0] - - trace watchpoint hit 56 wphit[1:0] - -
153 32002f?03/2010 avr32 9.11 ocd register summary use the index shown in the "register index" column when accessing ocd registers by the nexus access mechanism (see section 9.3.2 on page 109 ).use the index shown in the "mtdr/mfdr index" column when accessing ocd registers by mtdr/mfdr instructions from the cpu (see section 9.2.10 on page 98 ). these indexes are identical to the register index multi- plied by 4. table 9-64. ocd register summary register index mtdr/mf dr index register access type page 0 0 device id (did) r page 100 1 4 reserved ? 2 8 development control (dc) r/w page 104 3 12 reserved ? 4 16 development status (ds) r page 106 5-6 20-24 reserved ? 7 28 reserved ? 8 32 reserved ? 9 36 reserved ? 10 40 reserved ? 11 44 watchpoint trigger (wt) r/w page 125 12 48 reserved ? 13 52 data trace control (dtc) r/w page 136 14?15 56-60 data trace start address (dtsa) channel 0 to 1 r/w page 136 16-17 64-68 reserved ? 18?19 72-76 data trace end address (dtea) channel 0 to 1 r/w page 136 20-21 80-84 reserved ? 22 88 pc breakpoint/watchpoint control 0a (bwc0a) r/w page 123 23 92 pc breakpoint/watchpoint control 0b (bwc0b) r/w page 123 24 96 pc breakpoint/watchpoint control 1a (bwc1a) r/w page 123 25 100 pc breakpoint/watchpoint control 1b (bwc1b) r/w page 123 26 104 pc breakpoint/watchpoint control 2a (bwc2a) r/w page 123 27 108 pc breakpoint/watchpoint control 2b (bwc2b) r/w page 123 28 112 data breakpoint/watchpoint control 3a (bwc3a) r/w page 124 29 116 data breakpoint/watchpoint control 3b (bwc3b) r/w page 124 30 120 pc breakpoint/watchpoint address 0a (bwa0a) r/w page 122 31 124 pc breakpoint/watchpoint address 0b (bwa0b) r/w page 122 32 128 pc breakpoint/watchpoint address 1a (bwa1a) r/w page 122 33 132 pc breakpoint/watchpoint address 1b (bwa1b) r/w page 122
154 32002f?03/2010 avr32 34 136 pc breakpoint/watchpoint address 2a (bwa2a) r/w page 122 35 140 pc breakpoint/watchpoint address 2b (bwa2b) r/w page 122 36 144 data breakpoint/watchpoint address 3a (bwa3a) r/w page 123 37 148 data breakpoint/watchpoint address 3b (bwa3b) r/w page 123 38 152 breakpoint/watchpoint data 3a (bwd3a) r/w page 123 39 156 breakpoint/watchpoint data 3b (bwd3b) r/w page 123 40?65 160-260 reserved ? 64 256 nexus configuration (nxcfg) r page 100 65 260 debug instruction register (dinst) r/w page 108 66 264 debug program counter (dpc) r/w page 109 67 268 reserved ? 68 272 debug communication cpu register (dccpu) r/w page 101 69 276 debug communication emulator register (dcemu) r/w page 102 70 280 debug communication status register (dcsr) r/w page 102 71 284 ownership trace process id (pid) r/w page 137 72 288 debug communication control register (dccr) r/w page 103 73 292 peripheral debug register(pdbg) r/w 74-75 296-300 reserved ? 76 304 aux port control (axc) r/w page 116 77? 255 308- 1020 reserved ? table 9-64. ocd register summary register index mtdr/mf dr index register access type page
155 32002f?03/2010 avr32 10. revision history doc. rev. date comments 32002f 2010-03-12 improved description of events and priority. replaced invalid reference in the ocd.pdbg register. note added about overall system interrupt latency. added msu system registers. 32002e 2009-09-01 added floating-point hardware description. 32002d 2009-08-01 added ocd dccpu and dcemu interrupts. added pdbg register for individual module masks. added avr32 architecture revision 3 secure state support. count/compare system register reset-on-match now programmable by cpucr corrected ldm, stm, and scall instruct ion cycle count in cycle count chapter. corrected maximum irq latency in the pipeline chapter. 32002c 2007-11-19 mpu compilant with revision 2 of avr32 architecture. added cycle counts for new instruction in version 2 of the cpu. added count/compare system register reset-on-match. added cpu local bus. reconfigured ocd axc register. 32002b 2007-08-03 added memory service unit (msu) description. added description of peripheral behavior in debug. 32002a 2007-03-30 initial revision.
i 32002f?03/2010 avr32 table of contents 1 introduction .............. ................ ................ ................. ................ ............... 2 1.1the avr family .........................................................................................................2 1.2 the avr32 microprocessor architecture .................................................................2 1.3exceptions and interrupts ..........................................................................................3 1.4java support .............................................................................................................3 1.5flashvault ................................................................................................................. 3 1.6microarchitectures .....................................................................................................3 1.7the avr32uc architecture .......................................................................................4 1.8avr32uc cpu revisions ..........................................................................................5 2 programming model ........... .............. ............... .............. .............. ............ 7 2.1architectural compatibility ..........................................................................................7 2.2implementation options .............................................................................................7 2.3register file configuration ..........................................................................................7 2.4the status register ...................................................................................................8 2.5system registers ......................................................................................................11 2.6compare and count registers ...........................................................................17 2.7configuration registers ...........................................................................................17 3 pipeline ........... ................. ................ ................. .............. .............. .......... 20 3.1overview .................................................................................................................20 3.2prefetch unit ............................................................................................................20 3.3decode unit .............................................................................................................20 3.4ex pipeline stage ....................................................................................................21 3.5support for unaligned addresses ............................................................................22 3.6forwarding hardware and hazard detection ............................................................22 3.7event handling .........................................................................................................22 3.8special concerns .....................................................................................................24 3.9entry points for events .............................................................................................26 3.10interrupt latencies ..................................................................................................37 3.11nmi latency ...........................................................................................................38 4 floating point hardware ..... .............. ............... .............. .............. .......... 40 4.1compliance .............................................................................................................40 4.2operations ...............................................................................................................40 4.3instruction set ..........................................................................................................42
ii 32002f?03/2010 avr32 4.4detailed instruction description ...............................................................................43 5 secure state .......... .............. .............. ............... .............. .............. .......... 59 5.1basic concept ..........................................................................................................59 5.2typical use scenario ................................................................................................59 5.3secure state boot sequence ....................................................................................60 5.4secure state debugging ..........................................................................................60 5.5events in secure state .............................................................................................60 6 memory system ......... ................ ................. ................ ................. .......... 61 6.1memory sections .....................................................................................................61 6.2memory interfaces ...................................................................................................62 6.3if stage interface .....................................................................................................62 6.4ex stage interfaces .................................................................................................62 6.5iram write buffer ....................................................................................................64 6.6memory barriers ......................................................................................................64 7 memory protection unit ..... .............. ............... .............. .............. .......... 66 7.1memory map in systems with mpu .........................................................................66 7.2understanding the mpu ..........................................................................................66 7.3example of mpu functionality .................................................................................70 8 instruction cycle summary .... ................ ................. ................ ............. 71 8.1definitions ................................................................................................................ 71 8.2special considerations ............................................................................................71 8.3cpu revision ...........................................................................................................72 8.4alu instructions ......................................................................................................72 8.5multiply instructions .................................................................................................75 8.6mac instructions .....................................................................................................76 8.7mulmac64 instructions .............................................................................................76 8.8divide instructions ...................................................................................................77 8.9saturate instructions ................................................................................................77 8.10load and store instructions ...................................................................................77 8.11multiple data memory access instructions .............................................................81 8.12branch instructions ................................................................................................82 8.13call instructions .....................................................................................................82 8.14return from execution mode instructions ..............................................................82 8.15swap instructions ..................................................................................................83 8.16system register instructions ..................................................................................83
iii 32002f?03/2010 avr32 8.17system control instructions ...................................................................................83 8.18read-modify-write instructions ..............................................................................84 8.19code example .......................................................................................................84 9 ocd system ................ ................ ................. ................ ................. .......... 87 9.1overview .................................................................................................................87 9.2cpu development support .....................................................................................90 9.3debug port ............................................................................................................109 9.4breakpoints ...........................................................................................................117 9.5program trace ........................................................................................................125 9.6data trace .............................................................................................................131 9.7ownership trace ...................................................................................................136 9.8memory service unit .............................................................................................138 9.9ocd message summary ......................................................................................149 9.10ocd message summary ....................................................................................151 9.11ocd register summary ......................................................................................153 10 revision history ....... ................ ................ ................. ................ ........... 155
32002f?03/2010 headquarters international atmel corporation 2325 orchard parkway san jose, ca 95131 usa tel: 1(408) 441-0311 fax: 1(408) 487-2600 atmel asia room 1219 chinachem golden plaza 77 mody road tsimshatsui east kowloon hong kong tel: (852) 2721-9778 fax: (852) 2722-1369 atmel europe le krebs 8, rue jean-pierre timbaud bp 309 78054 saint-quentin-en- yvelines cedex france tel: (33) 1-30-60-70-00 fax: (33) 1-30-60-71-11 atmel japan 9f, tonetsu shinkawa bldg. 1-24-8 shinkawa chuo-ku, tokyo 104-0033 japan tel: (81) 3-3523-3551 fax: (81) 3-3523-7581 product contact web site www.atmel.com technical support avr32@atmel.com sales contact www.atmel.com/contacts literature requests www.atmel.com/literature disclaimer: the information in this document is provided in connection with atmel products. no license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of atmel products. except as set forth in atmel?s terms and condi- tions of sale located on atmel?s web site, atmel assumes no li ability whatsoever and disclaims any express, implied or statutor y warranty relating to its products including, but not limited to, the implied warranty of merchantability, fitness for a particu lar purpose, or non-infringement. in no event shall atmel be liable for any direct, indirect, consequential, punitive, special or i nciden- tal damages (including, without limitation, damages for loss of profits, business interruption, or loss of information) arising out of the use or inability to use this document, even if atme l has been advised of the possibility of such damages. atmel makes no representations or warranties with respect to the accuracy or comp leteness of the contents of this document and reserves the rig ht to make changes to specifications and product descriptions at any time without notice. atmel does not make any commitment to update the information contained her ein. unless specifically provided otherwise, atmel products are not suitable for, and shall not be used in, automotive applications. atmel?s products are not int ended, authorized, or warranted for use as components in applications in tended to support or sustain life. ? 2007 atmel corporation. all rights reserved. atmel ? , logo and combinations thereof, avr ? and others are registered trademarks or trade- marks of atmel corporation or its subsidiaries. other terms and product names may be trademarks of others.

▲Up To Search▲

Price & Availability of AVR32UC10

	To Download AVR32UC10 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .